[omniORB] socket descriptors, ownership and threading
Duncan Grisby
duncan at grisby.org
Fri Oct 24 19:37:32 BST 2008
On Wednesday 22 October, "Jakob Happach" wrote:
> currently I'm trying to establish an omniORB for a new embedded system.
>
> I have already made experiences with porting omniORB 3.0.4 to a older
> version of this operating system.
[...]
> When creating a file descriptors, the creating process is registered
> as owner of the handle. Thus calls of other processes using this
> filehandle will result in an error like EBADF.
[...]
> As I have already almosted adapted the omniORB 4.1.3 I now face the
> problem of not knowing exactly the thread model of the new omniORB
> good enough to know if the are different threads used for creating,
> using and destroying the sockets.
omniORB is designed with the assumption of real threads with shared
resources, including memory and sockets. It's not likely to be a small
amount of work to change that.
I assume that the "processes" on the OS share an address space? If they
can't share memory, there's no hope.
> Currently I face the following questions:
>
> Are different threads used for creating, using and destroying sockets?
Yes.
> Which threads are used for creating, using and destroying the sockets.
A server has one thread per listening endpoint that accepts new incoming
calls and opens sockets for the new calls. It then hands off to other
threads to process the calls. In thread pool mode, the same thread
that's listening for new calls selects / polls the open connections and
assigns incoming calls to threads. That probably wouldn't work with a
scheme where sockets are owned by particular threads, although I suppose
you could keep transferring ownership between the select thread and the
workers. In thread per connection mode, one thread is dedicated to the
connection, so that seems more appropriate for you. The system normally
still allows other threads to service interleaved calls, though, but you
can turn that off with the maxServerThreadPerConnection configuration
parameter.
> Where a these threads created?
They're all created by the omniAsyncInvoker. See
include/omniORB4/omniAsyncInvoker.h and
src/lib/omniORB/orbcore/invoker.cc.
> Where would be the best points to forward a socket descriptor ownership?
SocketCollection is responsible to selecting on sockets and notifying
threads there's something to do. giopServer::notifyRzNewConnection is
where a new connection is handled. giopServer::removeConnectionAndWorker
is the entry point for closing a connection.
Hopefully that will point you in the right direction. As I say, it's not
going to be a simple change, I'm afraid.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list
mailing list