autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_SYS_RESTARTABLE_SYSCALLS


From: Ian Lance Taylor
Subject: Re: AC_SYS_RESTARTABLE_SYSCALLS
Date: 06 Sep 2003 16:02:25 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Paul Eggert <address@hidden> writes:

> Short summary: I surveyed uses of AC_SYS_RESTARTABLE_SYSCALLS in GNU
> code, and found only one use (in Bash), and it was used incorrectly.
> I therefore concluded AC_SYS_RESTARTABLE_SYSCALLS was not needed any
> more, and (worse) that it was confusing Autoconf users.

UUCP is GNU code which uses it.

> > The manual, and the program, suggest using sigaction with SA_RESTART.
> > This is obviously useless.  Firstly not every system supports
> > SA_RESTART
> 
> Which systems don't?  That info would be good to add to the manual.

I'm thinking of older systems.  As far as I know SA_RESTART was
introduced by Solaris.  I doubt it is in SVR4.2, for example, though I
admit that I don't have a way to check.  I checked Ultrix 4.0, and it
has sigaction but does not have SA_RESTART.  (On Ultrix, which is BSD
based, SA_RESTART is the default; sigaction() is a wrapper around
sigvec(), but sigaction() always sets sigvec()'s SV_INTERRUPT flag.)

> > AC_SYS_RESTARTABLE_SYSCALLS is for systems which do not provide
> > sigaction.
> 
> That part of the manual gives advice to people writing new code, and I
> think it's safe to assume SA_RESTART in newly written code.

It's not the manual, it's the program itself:

AC_DEFUN([AC_SYS_RESTARTABLE_SYSCALLS],
[AC_DIAGNOSE([obsolete],
[$0: System call restartability is now typically set at runtime.
Remove this `AC_SYS_RESTARTABLE_SYSCALLS'
and adjust your code to use `sigaction' with `SA_RESTART' instead.])dnl

> AC_SYS_RESTARTABLE_SYSCALLS is still in autoconf, so nothing has been
> broken (yet :-).  If people still need it for something, we'll keep it.

Sure, but why is it obsolete?

For me I guess it's a philosophical issue.  I think the point of
autoconf is to support a wide range of systems, including systems
which were created 10 years ago.  For example, in 1992 I ported UUCP
to SVR2 systems which had been built in 1984; autoconf was very
helpful.

What is the current autoconf philosophy?  How old should systems be
before they are no longer supported?  To put it another way, when can
autoconf start using shell functions?

Ian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]