[omniORB] omniORB 4 feature list

[Sai-Lai Lo]

>>>>> Peter Nyquist writes:

> Will there be any change regarding number of threads serving a single
> connection?

Yes, one of the enhancement that was done is to allow arbitrary number of
threads to send or receive requests on a single connection. This is
necessary to support GIOP 1.2 and bidirectional GIOP as well as to provide
a much more scalable server threading policy that can switch dynamically
from thread per connection to thread pool when the no. of connections is
much greater that the maximum no. of threads the system is willing to
provide.

> We had a problem with nested calls. The second call was blocked by the
> first?

I suppose this is an interoperability problem with another ORB. When a
server thread is doing an upcall, another thread is needed to look after
the connection in case there is another incoming call through that
connection. We can do this in 2 ways:

1. Always dispatch n threads (n > 1) to serve a connection.
2. Have 1 thread that do a select() on all the connections that do not have
   a server thread doing a receive. When a server thread is about to do an
   upcall, it notifies this "demultiplexing" thread to select() on the
   connection. 

I prefer 2) but 1) may also be available as an option.

I could have used a simpler implementation. For example, a single
demultiplexing thread plus a pool of worker threads and let the demux
thread do all the receiving. There are performance and memory resource
issues with this approach. My old paper on omniORB explains the current
design rationale in more details.

Sai-Lai


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND