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 ?
mainthread.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel