> -----Original Message-----
> From: Daniel Stenberg [mailto:daniel_at_haxx.se]
> Sent: Thursday, October 26, 2000 5:56 PM
> To: curl list
> Subject: Re: again: connect() timeouts
>
>
> On Thu, 26 Oct 2000, Georg Horn wrote:
>
> > i further investigated the problem with hanging connect()
> calls and the
> > alarm() timer. When installing a signal handler with the signal()
> > function, which is just a wrapper around sigaction(),
> signals are handled
> > in such a matter that syscalls are restarted after the
> signal handler has
> > finished.

I don't think I buy this. I believe the behavior of signal() is NOT to set
the SA_RESTART flag. If you didn't do this, you would never get an EINTR
from an interrupted system call due to an alarm, and alarm() would be pretty
darn useless! Sigaction() is a newer call which does offer the capability
of automatically restarting by use of SA_RESTART.

> >So we stay in the connect(), that hangs for
> minutes if a server
> > is unreachable.

I think something else is wrong. We get out of connect() on alarms. I just
tested this on our product on an SVR4 system, setting a one-second alarm on
connect() with the alarm signal catcher set with signal(). I got an error
with errno=EINTR from the connect() call. With alarm(0), the connect took
minutes to fail.

There may be portability issues, but I am doubtful. I've got to believe the
behavior of signal() would be pretty standard. What platform are you on?
Perhaps I should ask about this on comp.unix.programmer. Man pages do seem
to indicate that sigset() or sigaction() are the prefered way to set signals
over signal().

> >
> > But when we use sigaction() directly, we can specify via a flag that
> > syscalls should no be restarted, and then the connect() returns with
> > ernno set to EINTR after the alarm signal. So what about
> the following
> > patch?
>
> I'm amazed!
>
> You've really lit up my day! ;-) Thanks a lot for digging
> down into this and
> solving it beautifully.
>
> I just added a few '#ifdef HAVE_SIGACTION' lines to maintain
> portability, but
> otherwise your patch is applied as you posted it.
>
> That makes your perl scripts a lot fancier, doesn't it?
>
> --
> Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/
>

Cheers!
Rich
Received on 2000-10-27