[pulseaudio-discuss] Mono and SIGPWR interaction

[Lennart Poettering]

On Wed, 03.12.08 15:28, Jay L. T. Cornwall (jay at jcornwall.me.uk) wrote:

> 
> Hi,
> 
> A follow-up. I found this block in src/pulse/thread-mainloop.c:
> 
> /* Make sure that signals are delivered to the main thread */
> sigfillset(&mask);
> pthread_sigmask(SIG_BLOCK, &mask, NULL)
> 
> Sure enough, temporarily commenting this out fixes my problem. I 
> understand the reason for this code to exist, but it's unfortunate that 
> the PulseAudio client library forces such a PulseAudio-centric design in 
> order to interact with it when the majority of applications will have no 
> need for this.

Uh? This code is explicitly there not to confuse signal handling in
applications. It makes sure that signals are never delivered in the
thread created by the threaded mainloop, thus guaranteeing that when
the PA event loop is running the normal signal delivery maintained by the
application is not altered. 

I'd claim that doing this is the only right way to handle signals in
threads maintained by libraries. It's portable and increases compatibility.

OTOH relying on the availability of SIGPWR and that it is unmasked in
all threads is a serious and unportable limitation of mono. If you
want to call mono code from a PA threaded event loop callback than it
is probably a good idea to simply temporarily enable the signal for
the mono code and block it afterwards again. i.e.

callback() {
           sigemptyset(&mask);
           sigaddset(&mask, SIGPWR);
           pthread_sigmask(&SIG_UNBLOCK, &mask, &saved);

           /* ... now call into the mono code ... */
           
           pthread_sigmask(&SIG_UNBLOCK, &saved, NULL);
}

> Would it perhaps be possible to make signal capturing conditional on 
> pa_signal_init() being called? Obviously the code cannot simply be moved 
> into there, as it would run in the wrong thread, but something along 
> these lines?

Uh? pa_signal_init() is an API only used by application which would
like to hook up signal delivery to the PA event loop. It is not called
by libpulse itself.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4