Re: ORBit status?

[Tom Tromey <tromey cygnus com>]

>>>>> "David" == David Wragg <dpw@doc.ic.ac.uk> writes:

David> There are many details to a binary interface standard
David> though. I'll discuss this point (it is vital) somewhere else
David> though, because this message will be long enough without it.

Please do.  Start a new thread, or whatever.


>> The approach ILU takes is to reenter the event loop while waiting
>> for a return value.

David> There are difficulties with that approach if an ORB is both
David> sending and recieving requests. What happens if while waiting
David> in the event loop it recieves a request, and the object
David> implementation servicing that request issues another
David> request. It gets horribly tangled.

I'm not sure what you mean by "horribly tangled".  The stack could be
really deep, of course.  That's probably not a problem.

The basic idea is that each reentrant invocation of the event loop has
an associated termination variable.  The event loop basically looks
like:

	*terminate = 0;
	while (! *terminate)  dispatch_one_event ();

When a response to some request comes in, it just does:

	*terminate = 1;

(for the appropriate `terminate').  The terminator variables can be
stack-allocated.

This will correctly handle your scenario, and any other one.


David> So I do think this merits consideration, and if the general
David> conclusion is "use threads" then at least a decision has been
David> made up front, rather than not because the alternatives haven't
David> been considered.

My four main problems with this scenario:

1.  It introduces nonstandard language bindings.  This means that we
would have to require ORBit and no other ORB.  Maybe this isn't a big
deal (though I think it is).

2.  Time spent on this is time not spent on all the other things we
have to do.

3.  In practice the reentrant event loop model doesn't seem to cause
real problems.

4.  I'd rather not program in continuation passing style :-)


Unfortunately there's a whole different set of problems associated
with using threads.  For instance, Gtk isn't thread-safe (there's been
some work, but I don't think it is complete).  It's possible (or
likely, dunno) that the Gnome libraries aren't thread-safe either.

Also, threads are (still, sigh) less portable than an event loop.


Still, I think threadability (if desired) is an explicit goal of
ORBit.  I think I remember this from the initial ORBit announcement;
you'd have to dig through the gnome-list archives to find this.  Also
see ORBit/include/thread-safety.h (the existence of which at least
alludes to the idea).

Tom