Re: __attribute__((warn_unused_result)) for NetBSD?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Sep 16, 2008 at 12:59:41PM -0400, der Mouse wrote:
 > >> I thought syscall restart was an attribute of the signal, not the
 > >> call.  (Well, calls do have a "this call is restartable" attribute
 > >> too.)
 > > Traditionally, it's an attribute of the call.  Then POSIX stuck their
 > > oar in and decided it ought to be an attribute of the signal;
 > > unfortunately, that doesn't work,
 > 
 > Doesn't work?  In what sense?  (It looks reasonable to me; I'm
 > wondering what I'm missing.)

Well, consider select(). If your program has a select loop, then
generally your program will want to be blocked in select() and not
elsewhere, and in general it may also block in select() for long
periods of time. Then suppose you want to catch some signal. (Common
cases include SIGCHLD if you also have subprocesses, or SIGHUP if
you're a daemon with config to reload.) Recall that a signal handler,
being an interrupt, is roughly speaking not allowed to do anything
other than assign a value of type sig_atomic_t. Thus, your program
blocked in select() for long periods of time relies inherently on
whatever signal you're trying to catch resulting in select() returning
EINTR and *not* being restarted. Only that way can it test the flag(s)
set by your signal handler(s) and take suitable actions.

But if restart is an attribute of the signal, rather than the call,
you have to go hunt down every other system call in your program and
make sure that it retries on EINTR. Or (alternatively) hunt down all
the places in your program that you need to insert sigprocmask() calls
to make things safe. Typically, this is a hassle ranging somewhere
from "extremely annoying" to "flatly impossible", depending on the
overall quality of the code and the number of 3rd-party libraries
you're dealing with.

 > > so now it's sort of both and the real semantics are poorly specified.
 > 
 > Well, yeah, if POSIX didn't bother specifying exactly what they meant,
 > I can see that would be a problem.

No, they did (AFAICR); it's just wrong.

-- 
David A. Holland
dholland%netbsd.org@localhost