httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: lingerout()
Date Mon, 14 Apr 1997 05:21:48 GMT
On Sun, 13 Apr 1997, Roy T. Fielding wrote:
> 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?

I'm not sure all interrupts are bad.  Umm... right now we're probably OK
with this.  EINTR hasn't ever really equated to Bad Thing in my mind, just
that the call was interrupted.  Maybe we should have a Bad Thing global
variable set by our interrupt handlers which causes buff to just give up.

> 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.

Oh I see what you mean.  Right now EOUT is checked only on entry to the
functions ... but you're suggesting that we use EOUT to represent the
global I'm talking about above.  So the signal handlers would set EOUT
and the buff routines could gracefully fail.

But suppose another module (i.e. proxy) is using buff.c for its code, then
our signal handlers couldn't really know what buff to set EOUT on.

Dean


Mime
View raw message