Erik Slagter wrote: > John Haxby wrote: > >> I bet someone somewhere is using signal(3) instead of sigaction(2). >> signal() is the old interface which has some unpleasant side effects >> -- for example, the handler is reset to the default once the signal >> has been delivered. In the bad old days the first thing your signal >> handler did was to ignore the signal and the last thing it did was to >> reinstall the handler. That's horrible. On the other hand, if you >> use sigaction() then the signal will be pending signals blocked (not >> ignored) while you're in the handler and the handler will also remain >> in place. > > From man 2 signal: > > "The original Unix signal() would reset the handler to SIG_DFL, and Sys- > tem V (and the Linux kernel and libc4,5) does the same. On the other > hand, BSD does not reset the handler, but blocks new instances of this > signal from occurring during a call of the handler. The glibc2 library > follows the BSD behavior." > > In other words, in a slightly modern system using glibc2 (that would > be any system installed between now and ten years ago), the semantics > of signal() are quite sane and similar to sigaction, although this is > not portably guaranteed by the API. My man page says the same. I wonder if there's a bug in glibc-2.7? This definitely bit me on Fedora 8. I'm pretty sure that the failing program didn't define _XOPEN_SOURCE. jch ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
