Hi Guys.. quick question...
Im new to the concept of signals, so this might sound stupid,
BUT....

I believe the alsa library uses SIGIO to drive the
asynchronous *give me more sound data* callback functions.

In the future, im also planning on incorporating
a library ( written by a 3rd party ) into my software
that accesses some hardware over a serial port, which i beleive can also use SIGIO to report that data is ready to be read.

I take it that theese two libraries are going to conflict !?
one will overwrite the others signal handler via sigaction !?

Or is linux doing somthing clever going on behind the scenes that
calls both signla handlers ?

I would guess this kind of problem arises frequently, but google turned up nothing... should i start re-thinking my design now!?

Thanks!

Chris.

The short answer is it depends.

Linux does not do any magic: there can only be one signal handler per signal for a process. You cannot escape the limitation using threads, either: all threads have the same signal handlers in a process.

However, signals can be chained. It is not that hard to implement, either. Most programmers just do not bother to. Whether ALSA or your 3rd party library chains the signals, I have no idea.

If I were to guess, I'd say they will conflict. I don't believe either library chains their signals.

If you were to recompile one or both libraries for your application, you could of course use another signal, perhaps a realtime signal (SIGRTMIN+n), instead of SIGIO. All the kernel interfaces allow the process to specify a different signal, so it is just a question of whether the library supports it. For ALSA, it is defined when the library is compiled.

There are various ways to solve the signal conflict, if you wish to rely on the libraries being already installed on the system. The simplest, and usually the best one, is to separate the two parts -- ALSA access and the 3rd party library access -- into separate processes, and have the two parts communicate via pipes or sockets. The reason this is usually the best one, is that you'll find that the requirement for the pipe/socket communications creates an abstraction you can use to split your application into more easily managed chunks. Eventually, you might find that you could very easily replace the ALSA interface with something totally different. Usually the same applies to the hardware interface parts.

Think of the slave process(es) as interface processors, doing all device-specific magic, only working with abstract, device-independent data (formats) with other processes of your application. You'll usually have a third, master process, which controls and directs the actions of the other processes.

1 members found this post helpful.

Thanks Nominal Animal.

I like the named pipe idea.
There would be a little extra work to do in coordinating the slave processes,
but not having to poll is very desireable.

THANKS!