no threads

[Arne Christensen]

Maximilian Ott writes:
> 
> Hi,
> 
> 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.

Except that the only way to prevent deadlocks is to have extra threads
that handle connection requests etc.

> 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.

I did not plan to announce this just yet, but a direct question makes
a difference:

I managed to get a single-threaded version of omniORB up and running for
the first time just a couple of days ago. I plan to post the changes
(which are not that large really), but I still have some problems with
stability, so I'd like to wait a few days.

What I have so far replaces the socket recv() call that waits for the 
response to a call to an object (in the lowest level of the ORB code). It is
replaced by a select() call so that a this point the following can be
handled:
- the response to the object call that was made
- connection requests from clients
- calls from clients

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

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.

Does this sound like matching your needs?

-- Arne