Date: Mon, 20 Jun 2011 00:26:39 +0300 From: Mikolaj Golub <trociny@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-net@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: Scenario to make recv(MSG_WAITALL) stuck Message-ID: <86r56p7bsg.fsf@kopusha.home.net> In-Reply-To: <20110619094403.GD48734@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Sun, 19 Jun 2011 12:44:03 %2B0300") References: <86pqmhn1pf.fsf@kopusha.home.net> <20110614092303.GG48734@deviant.kiev.zoral.com.ua> <86k4cntwz2.fsf@in138.ua3> <20110619094403.GD48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86r56p7bsg.fsf>