You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU> on 1997/04/14 06:07:58 UTC
Re: lingerout()
>http_main.c:
>
> static void lingerout(sig)
> int sig;
> {
> if (alarms_blocked) {
> alarm_pending = 1;
> return;
> }
>
> if (!current_conn) {
> #if defined(USE_LONGJMP)
> longjmp(jmpbuffer,1);
> #else
> siglongjmp(jmpbuffer,1);
> #endif
> }
> current_conn->aborted = 1;
> }
>
>That doesn't look right to me. This is doing something similar to a
>soft_timeout but it needs to do something similar to a hard_timeout.
The difference between a soft_timeout and a hard_timeout is that the
former needs to check for the abort condition before repeating a
possibly-blocked action.
>This is bad, especially if the system restarts system calls. I haven't
>looked in too much detail, but there has been a report or two of
>processes hanging in 1.2b8; perhaps this is the cause?
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.
.....Roy
Re: lingerout()
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 13 Apr 1997, Roy T. Fielding wrote:
> 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.
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
Dean