[Xcb] [Patch] Fix busy-loop on BSD

[Uli Schlachter]

On 01.03.2012 21:14, Josh Triplett wrote:
> On Thu, Mar 01, 2012 at 08:50:19PM +0100, Uli Schlachter wrote:
>> attached is a patch with a relatively verbose commit message. I tested this on
>> one of my university's FreeBSD boxes (with quite a patches userland). I were
>> able to reproduce the original problem and the patch made it go away.
>>
>> At first I wanted to do just what Josh suggested. However, read_block() could
>> busy loop, too. This would happen if just the first part of an event or reply is
>> received while the rest of it is stuck somewhere. While this should never occur
>> in any real world scenarios, it still means that using MSG_WAITALL on a
>> non-blocking socket is always wrong.
> 
> As far as I can tell, read_block will always wait until it reads the
> requested amount of data.  If recv returns with less than the requested
> amount of data, read_block will wait for more data and call recv again.
> Given that, how could MSG_WAITALL cause you to block in the kernel in
> any situation where you wouldn't just loop in userspace?

The problem isn't that something gets struck in kernel.

So let's say read_block() wants to read 100 bytes from the connection, but the
TCP socket has only 30 bytes ready. recv() with MSG_WAITALL will fail on BSD and
not return any data, because non-blocking socket + MSG_WAITALL = exactly this
behavior.
Next, read_block() will call poll(). This immediately returns, too, because the
socket is readable (after all, there are 30 bytes ready to be read) and the
whole loop begins again.

So this will do a busy loop until all of the 100 bytes can be read. I am not
saying this will block.

So the summary still is: "On BSD, MSG_WAITALL is completely unusable on a
non-blocking socket and never the right thing to do"

I hope this makes it clearer what I meant.
Uli
-- 
"Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?" -- A. P. J.