[PATCH 2/2] Quickly retry sendmsg or recvmsg if errno is EAGAIN or EINTR.

Max Woodbury mtewoodbury at gmail.com
Wed Feb 26 20:40:01 CST 2014


On 02/26/2014 08:32 PM, Erich E. Hoover wrote:
> On Wed, Feb 26, 2014 at 6:10 PM, Max Woodbury <mtewoodbury at gmail.com> wrote:
>> ...
>> So it's mainly on style:
>>
>> -    I've been reading other peoples code for 50 years and that aspect
>>       of K&R is much easier to handle in my opinion.  Same with the
>>       extra blank line.  Other parts of wine use the style and are much
>>       easier to read as a result.
>>
>> -    And the miscount can't simply be ignored?
>
> Very little of Wine uses a blank line after an if, and I've never seen
> it with a single line statement.  That doesn't really matter though,
> the rest of the function (and really the whole file) is in Allman
> style and our current guidelines require matching the surrounding
> style.  (Note: I am not in charge of this, so debating me on the topic
> is pointless)
>
Bluntly Allman style sucks.  It is just plain hard to read.
Also, the blank line is associated with the 'return' and is often
used.

>> If you read kernel code, you'll find that just returning to
>> application level is sometimes enough to free the missing resource.
>> That happens often enough that a single quick retry on EAGAIN is
>> warranted.
>
> I'm not familiar enough with what you're trying to do, but if the
> buffer is full and the kernel throws back EAGAIN then it would seem
> that you're not in such a time crunch that waiting for the higher
> level to handle it is going to be a problem.  I could be wrong though,
> I don't do a lot of high-throughput socket programming.
>
Not a buffers full problem.  Internal locks that get released from a
thread switch and things like that.  Worth ONE retry to see if they
clear.  If its still stuck on the second attempt, punt.  And it's not
me, it's the game...

>> Bringing the relevant part of the retry code down and applying it to
>> only those parts where is has a strong likelihood of doing the most
>> good is exactly what the patch does.  If one retry is not enough, then
>> higher level strategy is needed so no changes are called for on the
>> higher level.  A loop at this level is _not_ a good idea since there
>> would have to be something to break the loop if it runs too long.
>
> I believe that Ken was suggesting that there are ways to do this such
> that the higher level can handle EGAIN and the lower level EINTR.  In
> my, admittedly limited, experience with this issue his suggestion
> seems reasonable, but I could be wrong.  However, I am sure that if
> you put together a convincing test case that it will make getting the
> patch accepted a lot easier (though not guaranteed).
>
TEST CASE?!?  Not!  Multi-thread with graphics throwing interrupts
left and right!  Disk interrupts.  Real internet delays.  Instead,
just watch the game with the problem for a day or two.  Better read a
few good Unix programming text.  Ask the impossible why dont'cha.

>> In other words, this fiddle is based on several decades of experience with
>> kernel and bottom level application debugging experience.  At
>> least look at it and test it before rejecting it on superficial grounds.
>
> Please do not be confused, I am not in charge of acceptance/rejection.
>   I have, however, been involved in Wine long enough to know that if
> you don't address the issues mentioned on this list (either with an
> explanation, the addition of new tests, or changing the code to handle
> the case mentioned) then AJ will usually reject the patch.
>
Yep. If it were possible, I'd do just that, but it's not...  On the
other hand, forgetting a CC is bad. (Fixed.  Want to compare years on
the list?  I've a few...)

> Best,
> Erich




More information about the wine-devel mailing list