[Orbit-python-list] Status update

[Roland M. <ma...@ec...>]

  It's getting like a habit :-)  Today's batch of (mostly good) news
about ORBit-Python:

- as far as I can tell, there only subsists one memory leak.  Every
  time you invoke poa.servant_to_reference, you leak some hundreds of
  bytes.  How much precisely depends on how your ORBit is configured
  (/etc/orbitrc allows you to activate IIOP on IPv4, IIOP on IPv6 and
  Unix sockets for your CORBA communications).  If you have IIOP on
  IPv4 and Unix sockets, that'll be 451 bytes, plus or minus one byte
  (don't ask me why).  For every call to poa.servant_to_reference ().
  I'm investigating that point, but I have to admit I feel a bit stuck
  there.  Maybe when it's a decent time of the day I'll be more
  inspired...  Anyway, the IOR profiles thingy gives me a lead to
  investigate.

- other leaks have been fixed, mainly the one about instanciating,
  activating and deactivating objects.  No leak there that I can see.

- there's a bug somewhere causing segmentation faults.  If you take
  the test suite I posted yesterday, and run it as is, you'll probably
  run into a segfault in the server when calling the
  create_and_destroy () method (run './client 10000 c').  Apparently,
  using a global new_instance (as suggested by the comment) is a
  workaround, but I don't like that either.

- fixed another bug somewhere in client.c (I think) that DECREF'ed an
  object once too much, resulting in segfaults too.

- I haven't done any benchmarks yet, but I suspect there'll be a
  slight performance increase, since I made plenty of things static
  when they were dynamic.  Of course, the static memory usage went up
  to compensate, but if we consider that the leaks have been
  plugged...  Oh well, it should be stable first.

Have a nice day, or night, or whatever it's called on your planet.

Roland.
-- 
Roland Mas

Using a big hammer without caution can cause big damage.
  -- PostgreSQL documentation, chapter 42