[omniORB] omniORBpy & omniORB 3.0 Object Deactivation from It's Own Method?

[Duncan Grisby]

On Tuesday 9 May, Randy Wiser wrote:

> What I'm trying to do is get the POA to release it's reference to an
> unneeded object, so the memory can be reclaimed.  This seems to work
> fine with the latest versions of omniORBpy and omniORB 3.0 (or 2.8)
> from Python code running external to the object that is being
> deleted/deactivated.
[...]

> If I try again using omniORB 3.0 (still from the server's address
> space), then I can get deactivation to happen, but only with the
> threading workaround in the enclosed file.  If the file is run as-is
> (no workaround) execution (as traced by IDLE) seems to enter one of
> the omniORBpy libraries and never return.

This is a bug which I fixed a week or two ago. If you get the most
recent version of omniORBpy from CVS or the FTP snapshots, your
example program will work fine. There's still a problem with the 2.8
version. I'll look into it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --