orbit-python-list

[Orbit-python-list] orb.run with threads

[Joseph T. B. <jb...@tj...>]

Hey folks, I'm trying to use the orbit orb to make several objects in
a system that I'm writing availalbe to other processes.

Problem is this: I have one process with several threads (around 5)
that runs fine.  But I want to be able to control it at times remotely
from a client program.  But wheneverer I incorporate corba into the
server and eventually run orb.run(), even in a separate thread,
everything else comes to a screeching halt.

Does this have something to do with the "global interpreter lock" that
I've heard so much about?

As I look at this further i've begun to wonder how you can write a
gtk/corba(ORBit) application when I need to call gtk_mainloop and
orb.run but yet neither of them returns until the program wants to go
away.  It seems that you would need to be multithreaded, but yet all
of the evidence i've seen so fars indicates that python-orbit, and
perhaps even orbit itself are not thread safe.

as you can probably guess, I'm a little confused and I'm probably
missing a few pieces of the puzzle.  any help greatly appreciated!

jb

-- 
------------------+
  Joseph T. Bore  |
 jb...@TJ... |
------------------+

Re: [Orbit-python-list] orb.run with threads

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

> As I look at this further i've begun to wonder how you can write a
> gtk/corba(ORBit) application when I need to call gtk_mainloop and
> orb.run but yet neither of them returns until the program wants to go
> of the evidence i've seen so fars indicates that python-orbit, and
> perhaps even orbit itself are not thread safe.

This is true.  ORBit-Python definitely isn't reentrant, and I don't think
ORBit is either.  (Rumor has it there is or was some work done in this area,
but I don't know what the status is.)

What you really want is Gnorba.  Basically, Gnorba (among other things)
provides a new main loop that handles both gtk+ and ORBit main loops.  This
is something I always wanted to do (and was partly my motivation for writing
ORBit-Python), but I never did get around to it.

I would certainly be pleased to see some work done in this area, and I'd
be happy to work on that (or help work on that) once I stabilize ORBit-Python
itself.  Check out: http://developer.gnome.org/arch/component/gnorba.html

Cheers,
Jason.

Re: [Orbit-python-list] orb.run with threads

[Joseph T. B. <jb...@tj...>]

Jason Tackaberry writes:
 > > As I look at this further i've begun to wonder how you can write a
 > > gtk/corba(ORBit) application when I need to call gtk_mainloop and
 > > orb.run but yet neither of them returns until the program wants to go
 > > of the evidence i've seen so fars indicates that python-orbit, and
 > > perhaps even orbit itself are not thread safe.
 > 
 > This is true.  ORBit-Python definitely isn't reentrant, and I don't think
 > ORBit is either.  (Rumor has it there is or was some work done in this area,
 > but I don't know what the status is.)

actually the more I think about it, orbit doesnt really worry me that
much since it's in a different process space.

 > What you really want is Gnorba.  Basically, Gnorba (among other things)
 > provides a new main loop that handles both gtk+ and ORBit main loops.  This
 > is something I always wanted to do (and was partly my motivation for writing
 > ORBit-Python), but I never did get around to it.

This interests me, but unforunately I was only musing about the
difficulty of using gtk and orbit.

For now I just need to use python-orbit and threads.  gtk is the next
step, so you can bet I'm going to be back... 8)

Now here is where my naivete comes in about extending the python
interpreter.  Is it possible to have pyorbit release the lock right
before it blocks and then after it unblocks, re-aquire the lock?  It
just cant be that simple I'm sure.

I'd be willing to help out with this, but I'm going to probably need
some help figuring out some of the internals that I dont know already.

 > I would certainly be pleased to see some work done in this area, and I'd
 > be happy to work on that (or help work on that) once I stabilize
 > ORBit-Python itself.  Check out:
 > http://developer.gnome.org/arch/component/gnorba.html

if all goes well i'd help out there too.

jb

-- 
------------------+---------------------------------------------------------
  Joseph T. Bore  | When you have tremendous conviction on a trade, you have
 jb...@TJ... | to go for the jugular.  It takes courage to be a pig.
------------------+---------------------------------------------------------

Re: [Orbit-python-list] orb.run with threads

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

> Now here is where my naivete comes in about extending the python
> interpreter.  Is it possible to have pyorbit release the lock right

I don't know about pyorbit, but I'm sure it's possible with ORBit-Python. :)
(PyOrbit is a different project.)

> before it blocks and then after it unblocks, re-aquire the lock?  It
> just cant be that simple I'm sure.

As I understand it, this is pretty much how it must work.  However, with
the sort of arrangement in ORBit-Python it might not be so clear cut.  

On the server side, you'll need to release the lock before calling
CORBA_ORB_run().  Then in operation_skel, reclaim the lock and release
it after exiting.  On the client side, you'd release the lock before
invoking any of the GIOP calls (which can potentially block for a
long time if over a slow connection), and then reacquire it after.

Feel free to give this a whirl and let me know how it goes.

> I'd be willing to help out with this, but I'm going to probably need
> some help figuring out some of the internals that I dont know already.

If you have any questions, by all means ask on the list.  I'm sure either
myself or Roland (or someone else in the know) will get back to you.

> if all goes well i'd help out there too.

Glad to hear it!

Cheers,
Jason.

Re: [Orbit-python-list] orb.run with threads

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

* Jason Tackaberry (ta...@li...) [000825 12:18]:
> CORBA_ORB_run().  Then in operation_skel, reclaim the lock and release
> it after exiting.  On the client side, you'd release the lock before
     ^^^^^

Of course I meant _before_ exiting.  Releasing a lock after exiting would
surely be an impressive accomplishment! :)

Sheepishly,
Jason.

Re: [Orbit-python-list] orb.run with threads

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

Joseph T. Bore (2000-08-25 11:04:56 -0400) :

> Does this have something to do with the "global interpreter lock"
> that I've heard so much about?

I'm not enough of a CORBA guru to be able to answer that one :-)

> As I look at this further i've begun to wonder how you can write a
> gtk/corba(ORBit) application when I need to call gtk_mainloop and
> orb.run but yet neither of them returns until the program wants to
> go away.

  Yep.  This is probably not the answer you're expecting, but another
question instead: do you really need your Gtk application to be the
CORBA server?  What I personally do is that my CORBA server is a sort
of daemon, with very little user interaction (except for the command
line), and the monitoring application is another one, functioning as a
CORBA client.

> It seems that you would need to be multithreaded, but yet all of the
> evidence i've seen so fars indicates that python-orbit, and perhaps
> even orbit itself are not thread safe.

  Judging by the fact that there's a project to make ORBit
thread-safe, I think it currently isn't :-/

  What you *could* do, though, is the following.  Assuming you can have
a CORBA client in a thread (which might be a long reach, but only
testing will show me right or wrong), you could have a single-threaded
server storing the objects, and your multi-threaded thing would be a
CORBA client, changing the objects on the server so that other clients
could use them.  It's ugly, I know, yeah.  But the other way is to
contribute to the multithread-safe'ing of ORBit, so take your pick.

  In any case, I suggest you ask on the ORBit mailing list.  See the
page at <URL:http://mail.gnome.org/mailman/listinfo/orbit-list> for
more info.

Roland.
-- 
Roland Mas

Just a little bit of you every day will surely keep the doctors away.
  -- Just a little bit of you (The Jackson Five)