Re: Multi-threaded

[Toralf Lund <toralf lund pgs com>]

Frank.Rehberger wrote:
> Toralf Lund wrote:
>   
> > First question: Is this list actually alive???
> >     
> Yes, the list is alive, but little conversation going on ;)
>
>   
> > Second question: Can anyone explain how to set up an ORBit2 server so
> > that it can process several requests in parallel via multi-threading?
> >
> >     
> Did you take a look at this page?
>
> http://projects.gnome.org/ORBit2/orbit-docs/orbit/x1223.html#AEN1229
>   
No. I didn't notice that example. Thanks.

I had actually tried parts of this, but I see at least one call that I'm 
assuming might make a difference:

*ORBit_ObjectAdaptor_set_thread_hint ((ORBit_ObjectAdaptor) child_poa, 
					     ORBIT_THREAD_HINT_PER_REQUEST);*

However, I don't really understand the example if it's supposed to run 
multiple threads. I mean, I can see only one extra thread getting 
created, and the original main thread doesn't do CORBA operations at 
all. But if there is just one thread doing CORBA, why do they bother to 
send "multi-threading" options to the POA?

> Taking a look at this sample code today, I would do it a bit
> differently, for example: instead of instanciating  a new ORB within
> each  thread,
Not sure I follow you. Like I said, I really can't see more than one 
thread of interest. Or does ORBit2 add others on it's own? Or did you 
intend to post another example that actually uses multiple threads for 
CORBA operations? I'll have a look around to see if I can find one...

>  one should instanciate only a single ORB instance once in
> main thread and invoke "run" from within each thread on it. The "run"
> operation will add the specific thread to thread-pool, waiting for new
> incoming requests to be processed.  This threading-model would be the
> most resource-efficient way.
>
> Does this help? May I ask you for the reason you look at CORBA,
> especially ORBit2? 
Simply put, we need to connect to a service provided by a supplier/sub 
contractor, and it uses CORBA. We have also introduced CORBA for 
communication between some components of our own, simply because it was 
there already.

ORBit2 was chosen because it integrates directly into the Glib main 
loop, and by extension, Gtk/GNOME and Qt applications - without the need 
for timer based polling and such like. And partly because it's 
preinstalled on typical Linux setups.

Other ORBs, which might otherwise be nicer simply because they are 
better documented, do not seem to offer the same level of integration.

>  If you are interested in realtime-like middleware,
> it might be worth to look at http://www.OpenSplice.org, which is a DDS
> data centric publish/subscribe framework, providing  scaling ,
> fault-tolerance and realtime as key features. DDS is also an open standard.
>   
I looked at DDS earlier as an alternative to some of our CORBA links and 
also various homemade TCP-based protocols that are in use, and found 
that it might be a good option, but for various practical and technical 
reasons I didn't go ahead and introduce it into the system at the time. 
Actually, this has to do with the fact that we should really look into 
our communication needs at a larger scale and standardise on one solution.
> Just in case you would like professional services for ORBit2 or
> OpenSplice DDS, you can contact  http://www.icoup-consulting.com
>   

OK. I'll keep that in mind...

- Toralf


This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.