MAIN_THREAD_MODEL POA

[m***@free.fr]

Hello All

I'm trying to use MICO to let our system communicate with external
apps using Corba.

Our system is composed of several apps that have a Gtk GUI and
communicate with each other using an in-house built messaging
system. This messaging system is integrated with the Gtk main loop, so
that main loop can dispatch either GdkEvent or our messages to the
appropriate processing callback. Therefore, our apps are (mostly)
single-threaded since they don't need to be MT aware.

I would like some of our apps to provide services to external apps, by
calling the existing code, just as they are doing now when they
process messages they receive from other apps of our system. So I've
compiled MICO with debugging enabled and tried to use a
MAIN_THREAD_MODEL POA but it doesn't seems to work. The request is
still processed by another thread created by MICO.

I've done my tests using slighly modified sources in the
demo/dispatcher/gtkmico directory. I've attached the sources to this
message.

While trying to make things work in the right way, I saw the following
code in poa_impl.cc:

if (!builtin_invoke (ir, servant)) {
CORBA::ServerRequestBase_ptr svr = ir->make_req (this, servant);
if (thread_policy->value() == PortableServer::MAIN_THREAD_MODEL) {
MICOMT::AutoLock t_lock(S_global_invoke_lock);
servant->doinvoke(svr);
} else if (thread_policy->value() == PortableServer::SINGLE_THREAD_MODEL) {
MICOMT::AutoLock l(serialize_invoke);
servant->doinvoke (svr);
} else {
servant->doinvoke (svr);
}
}

It seems that the MAIN_THREAD_MODEL only guarantees that invocation
are processed sequentially. This is correct by the Corba spec but I
need invocations to be processed by the main thread to be sure that:

1. No other GdkEvent is beind processed concurrently.

2. The processing code can make changes to the Gtk GUI.

I might try MICO in a single-threaded configuration, but I'd prefer to
be able to use a MT-enabled POA if we ever need to do so for specific
services.

There is also a main_thread_id_ in the class ORB, but it's only used
by work_pending() and perform_work().

I started looking at Dispatchers, but I don't think it would be wise
to extend them to do invocation processing. IMHO, we can design a new
class hierarchy MainThreadProcessing that is responsible of processing
an invocation in the main thread. We could have in the class ORB a
pointer to an instance of a subclass of MainThreadProcessing that
knows how to interrupt the main loop in the main thread to process an
invocation.

Any idea, someone ?