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.
I think the best option to this problem would be to simply ignore the signal, possibly using signal() for ease of use or sigaction for correctness. This would solve the problem if the root of the problem is a multithreaded application where SIGIO signals are broadcasted to all threads instead of just to the "interested" thread.
If there is no multithreading involved, this is a bug and cannot be solved by the application; the alsa lib is not processing it's SIGIO signals so it can't work. But I guess it's the former case.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------- 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
