Re: (ITS#6276) paused pool can deadlock if writers are waiting

[hyc@symas.com]

Hallvard B Furuseth wrote:
> But I quite agree
> that this is hopeless if that "small" set cannot be kept small.  For one
> thing it might introduce yet another "lock order", threatening to be
> inconsistent with the lock order of other mutexes.

>> Another possibility is to just try to read 1 byte in the listener
>> thread, to detect the hangup there when we have no other means to
>> discover it. We would have to make sure to be able to unget this byte
>> back to the bottom of the sockbuf stack if there's valid data. This
>> will affect the throughput of the listener thread, but it may not be
>> too terrible a hit.
>
> Does that help for a socket which has gotten blocked on select() due to
> full socket buffers?

A socket that's blocked on a write will eventually clear itself up - either 
the client will catch up or it will go away. So there's really no reason to 
worry about them at all.

> Also if doing - a read() OS call anyway, why not read() a large enough
> chunk that it would commonly be a full PDU?  As long as it's read to a
> sockbuf buffer rather than into slapd's data.

Because we don't want to keep the listener thread busy for any longer than 
necessary. In terms of system call overhead it might be reasonable to read as 
much as one memory page (e.g. 4KB) but even that involves a lot of cycles for 
memcpy, and the idea is to shunt all the time-consuming work elsewhere so that 
the listener can return to listening ASAP.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/