Thread: [Orbit-python-list] Orbit-python and threading?
Status: Inactive
Brought to you by:
tack
From: Marijn V. <ma...@me...> - 2001-11-07 20:28:24
|
Dear listers, I am trying to get some program to work with python-orbit. Because I need it to do some more work besides just waiting for corba requests to come in, and i didn't see any "idle" hooks (ala gtk.py), My solution is to dump the Orbit run() in it's own thread, while the rest of the processing goes on in the mainthread.=20 Anyway, a strange thing happens, when I do that orb.run() the application blocks (surprise!) nomatter that it's running in it's own thread. If I replace the orb.run() with something like time.sleep(largenumber) the threading works as expected. I don't really know what the cause of this is, or what to do about it. Any help would be greatly apriciated. What am I doing that i shouldn't? And if i can't mix orb.run() with threads, how do i do some processing while orb.run() is just blocking waiting for requests?=20 I included the most relevant source snippit, maybe i am doing something very wrong, somehow... Regrads, Marijn. =20 --- Here's the code that does the threading: "sim" and "user" are two objects that hold the data the server has to work with and "lock" is a global lock so that the implementation class won't read/write to the data structures when an update of that data is going on. import CORBA, SimServer, SimServer__POA from threading import * import time class SimServer: def __init__(self, sim, user, lock): self._thread =3D Thread(target=3Dself.run, name=3D"Orbit") argv =3D [] argv.append('ORBIIOPIPv4=3D1') self.orb =3D CORBA.ORB_init(argv) self.poa =3D self.orb.resolve_initial_references("RootPOA") ref =3D SimServer_Sim_Impl(sim, user, lock)._this() open("server.ior", "w").write(self.orb.object_to_string(ref)) self.poa.the_POAManager.activate() # self._thread.setDaemon(1) print "pre thread start" self._thread.start() print "post thread start" def run(self): print "orb run" print enumerate() # time.sleep(500) self.orb.run() print "orb end" --=20 Get loaded from the source: Do Linux! Marijn Vriens <ma...@me...>=20 GPG/PGP: 6895 DF03 73E1 F671 C61D 45F4 5E83 8571 C529 5C15 |
From: Christian R. R. <ki...@as...> - 2001-11-07 20:36:06
|
On Wed, 7 Nov 2001, Marijn Vriens wrote: > I am trying to get some program to work with python-orbit. Because I > need it to do some more work besides just waiting for corba requests > to come in, and i didn't see any "idle" hooks (ala gtk.py), My > solution is to dump the Orbit run() in it's own thread, while the > rest of the processing goes on in the mainthread. Okay. This is a feature that we have been desiring for a while now, and if Tack thinks it's okay, i'd like to do a 0.3.2 pre-version that includes the ability to use the gtk mainloop. This does mean it's necessary to have pygtk installed and it requires a version of pygtk compiled without threads (or the latest pygtk with my patch to disable threading in runtime) but it does work. > Anyway, a strange thing happens, when I do that orb.run() the > application blocks (surprise!) nomatter that it's running in it's own > thread. If I replace the orb.run() with something like This is by design. Even noticed how pygtk blocks when you gtk.mainloop()? It's the same sort of idea. The server runs in a mainloop and in theory it is intended to only service user requests. If you do want to do client-side processing (have the server initiate actions/requests) then you will either need threads (which we don't support right now) or the gtk mainloop hack. I'm surprised your threading example doesn't crash, but I don't know threading very well at all. Tack? :) Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL |
From: Jason T. <ta...@li...> - 2001-11-07 22:04:08
|
On Wed, 2001-11-07 at 15:35, Christian Robottom Reis wrote: > Okay. This is a feature that we have been desiring for a while now, and if > Tack thinks it's okay, i'd like to do a 0.3.2 pre-version that includes Well this is certainly something for 0.4.0, and not 0.3.x. My first instinct was to reject this approach and say I'd much rather do it a less kludgey way (that is, make o-p thread-safe). Now that I think of it, I think that the orbit2 port Johan is working on is really the way to go with this one, because orbit2 is (purportedly) thread-safe. I suspect that 0.5.0 may not work out as I planned in the road map I posted a few months ago. I think I may focus on standards compliance for 0.4.0, since stability is nearly there now, and after that maybe help Johan with the orbit2 port. That said, I still maintain your patch is something for 0.4.0 and not 0.3.2, so we'll look at that more closely when the time comes. > I'm surprised your threading example doesn't crash, but I don't know > threading very well at all. Tack? :) It doesn't crash because orbit-python has the global interpreter lock before it calls ORB.run(), so essentially all the other threads get suspended. (Specifically, they're waiting for the interpreter lock to be released.) Jason. |
From: Christian R. R. <ki...@as...> - 2001-11-07 20:41:44
Attachments:
orbit-python-thread-fix
|
On Wed, 7 Nov 2001, Marijn Vriens wrote: > I am trying to get some program to work with python-orbit. Because I > need it to do some more work besides just waiting for corba requests > to come in, and i didn't see any "idle" hooks (ala gtk.py), My > solution is to dump the Orbit run() in it's own thread, while the > rest of the processing goes on in the mainthread. I've attached a patch to o-p from cvs that does the threading changes. You'll need pygtk compiled without threads (or from CVS with PYGTK_NO_THREADS env var set). You should initialize the orb using something like: orb = CORBA.ORB_init( [], CORBA.ORB_ID, CORBA.TRUE ) (the third parameter says you want to use the gtk mainloop. Then just substitute the orb.run() call for gtk.mainloop(). It should work. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL |