orbit-python-list

[Orbit-python-list] workaround for gtk+corba

[Brian C. <bc...@th...>]

Operating on the theory that the problem is the threading, I rebuilt pygtk w/o
thread support (orbit-python has it disabled with a #define).

This appears to work. The glade top window came up, and it was able to process
a servant method invocation via orbit. Whoohoo.

The failure case (as I understand it) was occurring because pygtk was doing a
thread save prior to gtk_main(), and then the first corba event would attempt
to call into python w/o doing a thread restore. Then I'd get the thread error.

Enabling threading in orbit-python merely caused it to fail in the same
callback, on thread restore. I suspect this is because it's attempting to
restore from an uninitialized variable (since it's normally initialized in
orb.run(), which is never invoked).

There seems to be a significant design problem here with the python thread
model. Perhaps python modules need to agree on a policy for storing thread
info, so it can be shared. I don't know if it's possible for modules to
share information.

b.c.

Re: [Orbit-python-list] workaround for gtk+corba

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

On Fri, 8 Feb 2002, Brian Craft wrote:

> Operating on the theory that the problem is the threading, I rebuilt pygtk w/o
> thread support (orbit-python has it disabled with a #define).

Yes, that's a known problem. Sorry to not have aided you before, but I
have been very busy this week with an article for FOSDEM and couldn't
concentrate.

If you use pygtk-0.6.9 it allows you to disable threading at runtime.

> There seems to be a significant design problem here with the python thread
> model. Perhaps python modules need to agree on a policy for storing thread
> info, so it can be shared. I don't know if it's possible for modules to
> share information.

I think it's possible, but Tack would be the person to comment on this.

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