Georg,

Sorry if my post seemed to doubt your findings, I do not. I was just
amazed, and therefore a little skeptical. I did indeed query the
comp.unix.programmer newsgroup and got the following response from the
maintainer of the Unix Programming FAQ himself:

<<<<
Subject:
             Re: Signal() sets SA_RESTART???
        Date:
             30 Oct 2000 14:04:34 +0000
       From:
             Andrew Gierth <andrew_at_erlenstar.demon.co.uk>
 Organization:
             disorganised
 Newsgroups:
             comp.unix.programmer
  References:
             1

>>>>> "Rich" == Rich Gray <richNOgSPAM_at_plustechnologies.com> writes:

 Rich> This just sounds wrong to me. Are there implementations of
 Rich> signal() which set SA_RESTART?

absolutely. In fact this is one of the main reasons why signal()
should not be used to catch signals - systems derived from (or
imitating) BSD usually set SA_RESTART, systems derived from SysV
don't. The only solution is to always use sigaction() instead.

-- 
Andrew.
comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>
>>>>
Soooo, it would seem that signal() on a BSD-derived system is indeed useless
for setting alarms and should be avoided for portable code...
Cheers!
Rich
> -----Original Message-----
> From: Georg Horn [mailto:horn_at_koblenz-net.de]
> Sent: Monday, October 30, 2000 3:15 AM
> To: curl_at_contactor.se
> Subject: Re: again: connect() timeouts
> 
> 
> 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
>