orbit-python-list

[Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

Here is an excerpt from the ChangeLog:

   * PortableServer.c: fixed a leak in activate_object(); implemented
     reference_to_servant(); removed deprecated method RootPOA(); removed
     the _servant attribute from servant implementation instances (this
     was a hack anyway)
   * marshal.c: fixed a leak in marshal_sequence and marshal_struct
   * CORBAmodule.c: changed CORBA_Object_to_PyObject_hash to hash on
     addresses, not typecodes; CORBA_PyObject__dealloc now properly frees
     the CORBA object; moved PortableServer module initialization into a
     separate file and module (PortableServermodule.c)
   * server.c: freeing a servant will deactivate it if necessary; fixed
     various leaks and bugs with the servant destructor; fixed a leak with
     exceptions in operation_skel; new_poa_servant adds new servants to the
     CORBA_Object_to_PyObject_hash so they can be fetched by reference_to_
     servant()
   * fixed CORBA_Environment leaks all over the place
   * fixed a few other leaks that I can't remember 
   * various debugging information added; the debug level is inconsistent
     all over the place -- this will need to be fixed.
   * removed Instance::throw_away function from test-suite.idl, replaced
     with Factory::discard_instance(); some other small changes to the
     test server and clients.

This commit represents a great number of leaks plugged.  Also, I'm
amazed the POA worked as well as it did; activate_object, deactivate_object,
and the servant's destructor were not done properly at all.  Things should
be working now.  Roland, please bang on this one and let me know if you
find anymore leaks.

I'd like to now focus my attention on standards compliance.  I'm going
to play with the idea for that "black magic" IDL directory scanning at
load time and see how that performs.  I'm tempted to say there won't be
a significant performance penalty, but we shall see.

Jason.

[Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

I went on a leak plugging frenzy tonight and along the way fixed a few
bugs too.  Roland, you'll be happy. :)

At this point there are no known leaks on either client or server side.
I plugged a few pretty obscure leaks, too.  Please file a bug if you
find more.

Jason.

Re: [Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

> At this point there are no known leaks on either client or server side.

Of course, this is only true if you're using ORBit 0.5.8, since 0.5.7
and earlier has leaks with CORBA_TypeCode and CORBA_Any.

Jason.

Re: [Orbit-python-list] Latest commits

[Christian R. R. <ki...@as...>]

On Mon, 28 May 2001, Jason Tackaberry wrote:

> > At this point there are no known leaks on either client or server side.
>
> Of course, this is only true if you're using ORBit 0.5.8, since 0.5.7
> and earlier has leaks with CORBA_TypeCode and CORBA_Any.

Was the POA bug we identified fixed? You know, the one where deactivate
doesn't clear out some fields on the servant's _private structure?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

> Was the POA bug we identified fixed? You know, the one where deactivate
> doesn't clear out some fields on the servant's _private structure?

You mean the ORBit bug?  I added a work-around to O-P's code.  That bug
(427468) is closed.

Jason.

Re: [Orbit-python-list] Latest commits

[Christian R. R. <ki...@as...>]

On Mon, 28 May 2001, Jason Tackaberry wrote:

> > Was the POA bug we identified fixed? You know, the one where deactivate
> > doesn't clear out some fields on the servant's _private structure?
>
> You mean the ORBit bug?  I added a work-around to O-P's code.  That bug
> (427468) is closed.

Any news from the orbit-list about the bug being valid and fixable/in the
process of fixing?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

> Any news from the orbit-list about the bug being valid and fixable/in the
> process of fixing?

Nope.  Not even an acknowledgement.

I'll file the bug on bugzilla.

Jason.

Re: [Orbit-python-list] Latest commits

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

Jason Tackaberry (2000-08-18 20:47:07 -0400) :

> This commit represents a great number of leaks plugged.  Also, I'm
> amazed the POA worked as well as it did; activate_object,
> deactivate_object, and the servant's destructor were not done
> properly at all.  Things should be working now.  Roland, please bang
> on this one and let me know if you find anymore leaks.

Yup.  Quick tests show zero leak.  Thanks a bundle!  I'll have to
update my main project since I relied on the ._servant attribute hack,
but thanks to my limitless faith in encapsulation, there should be
three lines to change in my code, and not three thousand.

  I'm, er, sorry for the ChangeLog file.  I'm just not used to
maintain one (too much CVS is bad for you, I guess).  I'll try to
remember for next time I commit things.

  And since 1. the code is apparently liable to change a bit these
days and 2. I've been working more on ORBit-Python than on Real Work
these days, I'll probably be rather quiet on this front this week or
so (I'll be on the IRC though).  Trust me to come back if I encounter
a bug or another leak, though :-)  That's the problem you'll have,
since my server will have to handle about a million objects and about
a million requests a day, any memory leak is forbidden, so I'll submit
patches and/or bug you until the last leak is dead.

  Speaking of patches, I suggest you close the appropriate patches
from the Sourceforge page, so as not to confuse people who might be
tempted to apply them on the CVS version.

Roland.
-- 
Roland Mas

Time passed, which, basically, is its job.
  -- in Equal Rites (Terry Pratchett)

Re: [Orbit-python-list] Latest commits

[Jason T. <ta...@li...>]

> Yup.  Quick tests show zero leak.  Thanks a bundle!  I'll have to

Good news.  Now all the changes I made over the weekend (massive
changes with the server side especially) have introduced other leaks.
I'll track these down today or tomorrow.

> update my main project since I relied on the ._servant attribute hack,
> but thanks to my limitless faith in encapsulation, there should be
> three lines to change in my code, and not three thousand.

More code breaking changes are still to come, unfortunately.  The
good news is the updates bring us closer to compliance with the spec,
and that the changes needed shouldn't be too drastic.  Such are the
perils of working with non-stable releases, I guess. :)  

After all is said and done, we should meet the spec as closely as possible.
Currently both inheritance and delegation is supported for implementations.
I interpreted the spec to say that inheritance is required while
delegation is optional.  Also, where things the spec is not too clear
on (such as _GlobalIDL), I'll copy omniORBpy.  At least then we'll be
as compatible as possible.

>   And since 1. the code is apparently liable to change a bit these
> days and 2. I've been working more on ORBit-Python than on Real Work
> these days, I'll probably be rather quiet on this front this week or

Just as well, I'll probably be tearing the whole thing apart. :)

> a bug or another leak, though :-)  That's the problem you'll have,
> since my server will have to handle about a million objects and about
> a million requests a day, any memory leak is forbidden, so I'll submit
> patches and/or bug you until the last leak is dead.

Interesting.  So what exactly are you using ORBit-Python for? 

>   Speaking of patches, I suggest you close the appropriate patches
> from the Sourceforge page, so as not to confuse people who might be
> tempted to apply them on the CVS version.

Yeah, I hadn't forgotten about that, just kept putting it off. :)  Thanks 
for the reminder.

Jason.