[omniORB] SocketCollection bug

[Duncan Grisby]

On Wed, 2010-01-20 at 16:40 -0800, Martin Kocian wrote:

[...]
> From the rtems code it seems clear that doing two blocking selects on
> the same socket won't work because the first thread to be woken up
> clears the rtems event that signalled that the socket had data waiting.
> So I think the question is if this is a bug in rtems or if multiple
> blocking selects (or select plus recv) on the same socket are not
> allowed for BSD sockets in which case it's a bug in omniorb.

I think it's a bug in rtems. I think it might be justifiable that if
there are two select() calls on the same socket only one wakes up, but
if there is a select() and a recv(), it must be wrong for the recv() to
not wake up when a later recv() would successfully return data.

As a work-around, assuming you don't configure your clients to multiplex
calls on a single connection (omniORB's default is not to), you can
prevent omniORB from doing the select() in this case by setting the
maxServerThreadPerConnection parameter to 1. That will mean it doesn't
try to watch for interleaved calls, avoiding the problematic situation
altogether.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --