Thread: [Orbit-python-list] Threading support
Status: Inactive
Brought to you by:
tack
From: Jason T. <ta...@li...> - 2000-08-26 18:30:23
|
I added the appropriate locks/unlocks to the code to support threading in Python. I tested it briefly and it seems to work, but there still may be problems. It only took me a couple minutes, and I'm skeptical to think anything is that simple. :) Let me know if you run into any bugs. From the ChangeLog: * server.c, client.c, CORBA_ORB.c: added necessary interpreter unlocking to support Python threads properly. (Not very tested, but seems to work.) Jason. |
From: Joseph T. B. <jb...@tj...> - 2000-08-28 12:29:11
|
rats, and I was determined to figure it out myself. Between corba, orbit, and extending the python interpreter, plus the threads code, it was taking me longer to wade throught it all than I thought. I had noticed that the tcl/tk module had essentially the same conditions for locking. So I was using it as a model. One piece of wisdom that I picked up from that work (_tkinter) was the fact that they have another lock that only lets one thread run inside the tcl interpreter at a time. I was concerned about this for the orbit-python module. Essentially they only hold the global interpreter lock or the tk lock exclusive (except for special cases) of each other. I imagine this may still be a problem? Or do you think this is a non issue? jb Jason Tackaberry writes: > I added the appropriate locks/unlocks to the code to support threading in > Python. I tested it briefly and it seems to work, but there still may be > problems. It only took me a couple minutes, and I'm skeptical to think > anything is that simple. :) Let me know if you run into any bugs. > > >From the ChangeLog: > > * server.c, client.c, CORBA_ORB.c: added necessary interpreter unlocking > to support Python threads properly. (Not very tested, but seems to > work.) > > Jason. -- ------------------+ Joseph T. Bore | jb...@TJ... | ------------------+ |
From: Jason T. <ta...@li...> - 2000-08-28 13:11:26
|
> Essentially they only hold the global interpreter lock or the tk lock > exclusive (except for special cases) of each other. I imagine this > may still be a problem? Or do you think this is a non issue? I'm tempted to say this isn't a problem, but I admit I don't completely follow you. Can you elaborate on the potential problem? Jason. |
From: Joseph T. B. <jb...@tj...> - 2000-08-28 13:38:23
|
My concern is that if someone unsuspectingly calls orb.run from different threads within the same process, is it a possibility that 2 threads could be inside the the corba module C code at the same time and step on each other? I imagine that if there is any I/O one thread could block, and then another thread would be able to scribble on the other's buffer. Or am I just being paraoid? 8) jb Jason Tackaberry writes: > > Essentially they only hold the global interpreter lock or the tk lock > > exclusive (except for special cases) of each other. I imagine this > > may still be a problem? Or do you think this is a non issue? > > I'm tempted to say this isn't a problem, but I admit I don't completely > follow you. Can you elaborate on the potential problem? > > Jason. -- ------------------+ Joseph T. Bore | jb...@TJ... | ------------------+ |
From: Jason T. <ta...@li...> - 2000-08-28 13:59:45
|
> My concern is that if someone unsuspectingly calls orb.run from > different threads within the same process, is it a possibility that 2 > threads could be inside the the corba module C code at the same time Why would you want or need to execute orb.run() in more than one thread? Assuming you did, ORBit might not like that too much. (Although I just tested it and it didn't seem to cause any problems, it just seemed to ignore one of the threads.) Anyway, the global interpreter lock saves us from the possibility of 2 threads being inside the CORBA module at once. The only exception is calling orb.run() in more than one thread, which shouldn't be necessary anyway. Jason. |
From: Joseph T. B. <jb...@tj...> - 2000-08-28 14:04:37
|
cool. Like I said, I was probably just being paranoid. jb Jason Tackaberry writes: > > My concern is that if someone unsuspectingly calls orb.run from > > different threads within the same process, is it a possibility that 2 > > threads could be inside the the corba module C code at the same time > > Why would you want or need to execute orb.run() in more than one thread? > Assuming you did, ORBit might not like that too much. (Although I just > tested it and it didn't seem to cause any problems, it just seemed to > ignore one of the threads.) > > Anyway, the global interpreter lock saves us from the possibility of > 2 threads being inside the CORBA module at once. The only exception is > calling orb.run() in more than one thread, which shouldn't be necessary > anyway. > > Jason. -- ------------------+ Joseph T. Bore | jb...@TJ... | ------------------+ |
From: Roland M. <ma...@ec...> - 2000-09-05 14:31:38
|
Jason Tackaberry (2000-08-26 14:35:06 -0400) : > I tested it briefly and it seems to work, but there still may be > problems. It only took me a couple minutes, and I'm skeptical to > think anything is that simple. :) Let me know if you run into any > bugs. I do run into a bug: Fatal Python error: PyThreadState_Get: no current thread Aborted This happens in a single-threaded CORBA server that just sent a request to itself (by accessing an attribute of an object that it happens to be hosting). I'm not sure, but it seems that it happens on the first time this situation (server calling itself through CORBA) occurs. The bug is entirely reproducible in my case (same thing happens every time I run my thing). I'll try and track it down a bit in a few days when I get some time. Meanwhile, consider this a bug report asking for attention :-) Roland. -- Roland Mas At a train station, the trains stop. At a bus station, the buses stop. I have a workstation on my desk... |