httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: lingerout()
Date Mon, 14 Apr 1997 05:05:58 GMT
>> Hmmmm, the calls to shutdown, select, and read cannot be restarted and
>> the first EINTR will cause the lingering to end.  Ah crap, the place
>> where it might occur is in bflush(), where it is looping on EINTR instead
>> of returning with -1.  I can't think of any case where we would want
>> a flush to continue after a signal is received, so I think that is bogus.
>Good luck fixing this... if you have an interrupted syscall anywhere
>in buff.c things are in a really screwed state (consider chunking)
>and cleanup is hard to do, which is why it's written to just continue.

But if it is in a screwed state, then we should return -1.  I don't see
any point in continuing to flush when we know something bad happened.
Am I missing something?  I guess the question is: are all interrupts bad?

>Here's some options:
>- if anything in buff.c gets an EINTR the stream is flagged "in error" and
>    no more i/o is permitted
>- we teach buff.c about soft_timeout and hard_timeout so that it can continue
>    after EINTR unless it's a timeout thing

We could do this just using the bsetflags, if the loop was rewritten
to check for the EOUT flag (as it should be anyway).  The same applies
to any looping on write in buff.c.


View raw message