Scenario to make recv(MSG_WAITALL) stuck

[Mikolaj Golub]

On Sun, 19 Jun 2011 12:44:03 +0300 Kostik Belousov wrote:

 KB> On Wed, Jun 15, 2011 at 09:44:33AM +0300, Mikolaj Golub wrote:
 >> 
 >> On Tue, 14 Jun 2011 12:23:03 +0300 Kostik Belousov wrote:
 >> 
 >>  KB> I do not understand what then happens for the recvfrom(2) call ?
 >>  KB> Would it get some error, or 0 as return and no data, or something else ?
 >> 
 >> It will wait for data below in another loop ("Now continue to read any data
 >> mbufs off of the head...").
 >> 
 >> Elaborating, I would split soreceive_generic on three logical parts.
 >> 
 >> In the first (restart) part we block until some data are received and also
 >> (without the patch) in the case of MSG_WAITALL if the buffer is big enough we
 >> block until all MSG_WAITALL request is received (actually it will spin in
 >> "goto restart" loop until some condition becomes invalid).
 >> 
 >> The second part is some processing of received data and the third part is a
 >> "while" loop where data is copied to userspace and in the case of MSG_WAITALL
 >> request if not all data is received to satisfy the request it also waits for
 >> this data.
 >> 
 >> My patch removes the condition in the first part in the case of MSG_WAITALL to
 >> wait for all data if buffer is big enough. We always will wait for the rest of
 >> data in the third part. It might be not so effective, and this is my first
 >> concern about the patch (although not big :-).
 KB> Now I think that this part of the patch is right.
 KB> The loop in the soreceive_generic() would behave as I would expect
 KB> it for MSG_WAITALL. It copyout the received data to userspace by
 KB> received chunks.

 KB> I do not understand your note about effectiveness there.

The old behaviour: if only a part of the request is recived and the buffer is
large enough, wait for the rest and then go to processing.

The new behaviour: if a part of data is recived, (unconditionally) process it
and wait for the rest (and process).

The first one looks a little more efficient (but has the issue for edge case
with nearly full buffer).

-- 
Mikolaj Golub