So, is it my bug or is it from ALSA?
On Jan 16, 2008 8:09 PM, John Haxby <jch@xxxxxxxxxxxxxxx> wrote:
Erik Slagter wrote:I think there was a problem with some versions of glibc. We had a bug
> 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 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
