cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: again: connect() timeouts

From: Georg Horn <horn_at_koblenz-net.de>
Date: Mon, 30 Oct 2000 09:14:44 +0100

On Fri, Oct 27, 2000 at 01:22:29PM -0400, Rich Gray wrote:

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

That _was_ just the behaviour of curl when signal() was used. Syscalls didn't
get interrupted and alarm() _was_ useless. It just called the signal handler
and then returned to the syscall.

> Sigaction() is a newer call which does offer the capability
> of automatically restarting by use of SA_RESTART.

Sure, and on systems that implement this newer call, signal() is just a wrapper
around sigaction(). From the manpage: "Both versions of signal are library
routines built on top of sigaction(2)."

> I've got to believe the
> behavior of signal() would be pretty standard.

Oh, standards are a nice thing, so everyone wants to have his own one.

> What platform are you on?

Linux with glibc-2.1.2, and that's the point i think. On older Linux versions,
there was no sigaction() and signal() behaved as you described. (BTW: What
platform are you on?) Now we have glibc, that offers the possibility to
automagically restart syscalls by setting the SA_RESTART flag, and
unfortunately they implemented the old signal() call by setting this flag and
then calling sigaction(). Well, things would be too easy if everything
would simply be compatible to the old libc... ;-)

> Perhaps I should ask about this on comp.unix.programmer.

Digging into the glibc-sources would be more enlightning i think...

> Man pages do seem
> to indicate that sigset() or sigaction() are the prefered way to set signals
> over signal().

So i think we don't do anythink wrong if we use something like:

#ifdef HAVE_SIGACTION
/* sigaction() stuff */
#else
/* old signal() stuff */
#endif

Bye,
Georg
Received on 2000-10-30