Re: ORBit2 threading patches ...

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi,

> 	Of course - ideally we need to steal^H^H^H^H^Hresearch Sebastian's
> thread pool stuff, and the way he handles dispatching. 

Thread pools are in GLib and should be usable right away. They might
still contain some bugs, because the still only testing ground
(ORBit-mt) is not very much used these days and is actually prety much
stalled. 

But of course there are only 2 thread pools needed for ORBit. One to
handle all PER_REQUEST requests and another one to provide all the other
designated threads handling either a connection, a poa or an object.

Then you have message queue on every individual thread. There you stuff
all incoming requests (as determined by the policy and the corresponding
object/poa/connection) and all incoming replies (as determined by the
thread, which sent out the corresponding request).

Then every thread waits on this message queue (GAsyncQueue) and in
general does exactly the same thing, as single-threaded-ORBit does in
its main loop. It e.g. has to support nested invocations, it has to save
still unwanted replies for later and so on.

> I think his
> situation is slightly simpler, we want to handle the case of an app's
> main-loop running away, and being able to mix and match things behaving
> in a very old-world Gtk+-style ST polling loop, and also trendy, MT
> concurrency :-)

If ORBit is running mutlithreaded you need the glib main loop with the
linc main loop context in exactly one thread (a dedicated thread
started, when CORBA_ORB_init is called). GTK+ programs might use another
main loop context (mostly the default one) themselves.

So linc will not add its fd's to the default context, if and only if it
is started multithreaded. In every case it will construct its own main
loop context, which for ST is run while waiting for incoming replies and
which for MT is run in a dedicated thread. 

Then the single thread dispatches all ORBit stuff according to the
policies.

This should all work out happily.

Just now I've no time (as usual), but I'm very glad seeing multithreaded
stuff moving into mainline ORBit2. 

Keep up the good work. ORBit2 really is worlds apart from ORBit in terms
of code quality.

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi@ira.uka.de
http://goethe.ira.uka.de/~wilhelmi