Re: __attribute__((warn_unused_result)) for NetBSD?
David Holland <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.general |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected]