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

[Duncan Grisby]

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