[Date Prev][Date Next]
Re: (ITS#6276) paused pool can deadlock if writers are waiting
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6276) paused pool can deadlock if writers are waiting
- From: email@example.com
- Date: Wed, 26 Aug 2009 09:33:24 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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/