no threads

[Sai-Lai Lo]

Hi Arne,

Nice to hear your success with getting a single-threaded version of
omniORB running.

A few comments:

1. It is better to complete your work with the coming release. In the past
   few weeks, I've restructured the low level part of the ORB to make it
   much easier to insert other network transports and thread models.
   I can make a snapshot of the current development tree available.

2. 

> This enables our application to call a server object and, while waiting
> for the response, to serve incoming calls to callback objects.

Does that means there could be two threads of execution in the same
process? Wouldn't this creates problem as the application assumes
everything is single-threaded.


3. 

> I plan on adding to this a polling procedure that the application can
> call whenever it feels like it in order to handle:
> - connection requests from clients
> - calls from clients

> We will need this in order to implement a notification mechanism. This
> polling procedure would need to be integrated into the event loop in
> our application.

AFAIK, most single threaded ORBs do the select() internally and let other
parts of the application, such as the GUI to hook up their sockets and
callback functions to this select loop. 

I wonder whether it is better to let the application do the select() and
the ORB registers its sockets and callback functions. In other words, a
generic class library for registering sockets and callbacks may be a better
way to integrate the ORB with other components of the applications. Could
someone point to a design pattern that do just that?

Regards,

Sai-Lai

-- 
E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research Lab
                                        |       24a Trumpington Street
Tel:            +44 223 343000          |       Cambridge CB2 1QA
Fax:            +44 223 313542          |       ENGLAND