[omniORB] select()-timeout in tcpSocketRendezvouser

Dr.-Ing. Martin Goettlicher Martin.Goettlicher@medical.bruker.de
Tue, 24 Apr 2001 16:35:27 +0200


Duncan Grisby wrote:
> 
> On Thursday 12 April, Dr.-Ing. Martin Goettlicher <martin.goettlicher@medical.bruker.de>  wrote:
> 
> > Among our programs using CORBA we have one small utility program
> > which is called from shell-scripts very often. This program simply
> > makes one CORBA-method call and terminates. Because the
> > shell-scripts were much slower than with the commercial ORB, I
> > investigated this problem further. I found out that the time (one
> > second) is consumed during orb->destroy() which waits for the
> > running threads to join. In the run_undetached()-method of the class
> > tcpSocketRendezvouser (omni/src/lib/omniORB2/orbcore/
> > tcpSocketMTfactory.cc line 1546-1548) there is a call to select()
> > with a timeout of one second. I patched this class using a much
> > shorter timeout and my problem seems to be solved. Because I don't
> > like to patch every new version of omniORB I would be > very happy
> > if this timeout could be configured for example via a command line
> > argument.
> 
> Hmm. Reducing the timeout in the select() call would make the
> selecting thread burn more processor time. A simpler solution is to
> not call orb->destroy(). That way, the process exits without trying to
> synchronise all the threads. The OS cleans up all the resources
> anyway.
> 
> Cheers,
> 
> Duncan.
> 
> --
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --

Dear Duncan,

thank you for your answer, which I'm unfortunately not satisfied with.
It was not my intention that you shorten the default timeout in
select(). For long running server applications one second is no problem.
However, for very short running processes it would be nice if the
timeout could be configured (ORBACUS for example is very flexible in
configuring timeouts) in trade of more processor time. I also would not
like to use your suggested workaround since I do not know if not calling
orb->destroy() will make problems when using Purify.

Cheers,

Martin