no threads

[Arne Christensen]

Sai-Lai Lo writes:
> >>>>> Maximilian Ott writes:
> 
> > We would like to incorporate omniorb into our system but have one problem.
> > For reasons I can explain offline, we don't want to use threads. Our
> > system is entirely event driven.
> 
> > If I understand the omniorb design documents correctly, this shouldn't be
> > a problem for the server side. It waits for an incoming request, processes
> > it and returns a result. This maps nicely on an event model.
> 
> > The client side is different. A call to a server object blocks the current
> > thread, which continous when the reply comes back. As an event model leads
> > itself to an asynchronous style, we can restrict all methods to be
> > "oneway". In this case the client would not need to block.
> 
> > How difficult would it be to take out the thread related stuff.
> 
> Firstly, it is possible to make omniORB non-threaded  with a few
> localised changes. However, I have my reservations on the general
> usefulness of single threaded ORBs. Take the following example:
> 
>       +------------+                           +-----------+
>       |Process 1   |                           | Process 2 |
>       | +-----+	   |       (1)                 |  +-----+  |
>       | | A  -+----+---------------------------+->| B   |  |
>       | |     |    |         (4)               |  |     |  |
>       | +-----+ <---------------------------------+-----+  |
>       |            |                           |  ^  |     |
>       |            |        (3)                |  | |      |
>       | +-----+-----------------------------------| |      |
>       | | C   |<---+---------------------------+----+      |
>       | +-----+    |	     (2)	       |	   |
>       +------------+                           +-----------+
>  
>   Object A calls Object B. Object B then do a nested call to Object C
>   before it replies to A. If A and C are in the same process, a single
>   threaded ORB would be deadlocked forever because process 1 would not
>   handle the incoming call to C until it receives a reply from B.

Right. However, this situation is explicitly handled by my changes, 
which by the way fit into the category "a few localized changes".
My compliments to the designer of that program!

> If your application is event-driven, making all methods oneway is probably
> a very natural mapping and single-threaded ORB would be sufficent. 


-- Arne