[omniORB] Re: Bug? Calls serialization in omni4.0.1

[Dmitry Davidovich]

Would shortening of "select" timeout (or better making it configurable) help
in this case?
As I undersatnd it defined to be 50ms
(SocketCollection::scan_interval_nsec).

Dmitry

> -----Original Message-----
> From: Duncan Grisby [mailto:duncan at grisby.org]
> Sent: Wednesday, 02 July 2003 15:36
> To: omniorb-list at omniorb-support.com
> Subject: Re: [omniORB] Re: Bug? Calls serialization in omni4.0.1 
> 
> 
> On Tuesday 1 July, baileyk at schneider.com wrote:
> 
> > In researching that, I developed a patch to awaken thread A 
> just before
> > thread B started it's upcall.  Unfortunately the patch only 
> works on a
> > Unix-like OS.  Duncan requested a patch that would work on 
> Windows too.  I
> > didn't have the time or resources to attempt that.  Later, 
> Duncan indicated
> > that something equivalent to my patch was included in 
> v4.0.1 (the above
> > discussion should be fairly accurate for v4.0.0).  I don't 
> know if he found
> > a way to get thread A to wake up on Windows too, or just 
> went with the fix
> > that works for Unix.
> 
> Kendall's summary of what's going on is correct (and well put --
> thanks Kendall). The change in 4.0.1 is essentially the same as
> Kendall's patch, since I gave up trying to think of a decent solution
> that would work on Windows as well as Unix.
> 
> The root of the problem is that in thread pool mode, there is a single
> thread watching all the idle connections, waiting for a new request to
> arrive on one of them. When it sees one, it picks a thread from the
> pool to deal with it. That thread reads the request, puts the
> connection back on the list to be watched, then does the call into
> application code. On Windows, there's no way to poke the watching
> thread into noticing that the connection is watchable again, so you
> have to wait until the watching thread times out and looks of its own
> accord.
> 
> There isn't any good way around the problem. One solution would be to
> have the watcher thread be the thread that unmarshals the request,
> before handing the unmarshalled arguments to another thread to do the
> upcall. That would be bad, since it would prevent concurrency between
> threads dealing with different connections. Another option would be to
> dedicate one thread per connection to just be a reader. That would be
> very wasteful of threads, and involve significant numbers of thread
> switches along the call chain.
> 
> The only half-way decent way I can think of doing it on Windows is to
> use a TCP connection through the loopback, to work in the same way as
> the pipe used on Unix. If someone wants to provide a clean patch to do
> that, I'll integrate it.
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
> 
>