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." I think there was a problem with some versions of glibc. We had a bug (in scalix, if you're interested) which was caused by signal() calling sigaction with the SA_RESETHAND and SA_RESTART flags. I'm not sure when this changed in glibc and whether it was just a bug on some specific platform. It can't find a machine where it is the case any more. 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
