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.