[omniORB] Deadlock in omniORB 4.0.6 ?

[Duncan Grisby]

On Friday 14 October, "Wernke zur Borg" wrote:

> I have one question concerning multiple threads dealing with one connection:
> What happens if thread #1 starts reading a long incoming message that is not
> completely available yet and that may additionally span the 8K buffer
> boundary. Is it possible that another thread is started to read the rest?

No. Each connection in omniORB is marked as either "selectable" or not.
Only when a connection is selectable is it watched by the thread calling
select(), which dispatches a new thread when it sees the connection is
readable. In the thread per connection mode, connections start off as
not selectable. When the dedicated thread has read a complete message,
it marks the connection as selectable in case another message arrives
while it is dealing with the first one. So, while the message is being
read, no other threads will handle it, no matter how big the message is.

At least that's what's meant to happen. In your case you have one thread
blocked in recv(), which is the state I'd expect to see the dedicated
thread in -- it's blocked waiting for a call to arrive. The mystery is
why all the other threads were triggered at all. Given that they have
been triggered for some reason, it's expected that they're blocked
waiting for the read lock on the stream, since the dedicated thread is
holding it. What we need to find out is not why they're blocked on the
read lock, but why they were dispatched in the first place.

I'm assuming here that all the threads are attempting to handle the same
connection. Does the server just have one client or many?

Cheers,

Duncan.

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