[pulseaudio-tickets] [PulseAudio] #430: Threaded mainloop API steals signals unnecessarily

[PulseAudio]

#430: Threaded mainloop API steals signals unnecessarily
------------------------+---------------------------------------------------
  Reporter:  jcornwall  |       Owner:  lennart
      Type:  defect     |      Status:  closed 
  Priority:  normal     |   Milestone:         
 Component:  libpulse   |    Severity:  normal 
Resolution:  invalid    |    Keywords:         
------------------------+---------------------------------------------------
Changes (by lennart):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 Hmm, we explicitly block all signals in the threaded poll to make sure we
 don't interfere with normal signal delivery. (the reason for that is that
 signal handlers are process wide, and if a process receives a signal it is
 not defined which thread it will be deliered too. To make sure that the
 signals are only delivered to threads that are maintained by the
 application programmer himself we thus block signals in all threads we
 maintain.) This is for compatibility reasons. Now, as it turns out, Mono
 doesn't like that since it (mis)uses signals for debugging purposes. If
 that's the case however it probably is a better idea to temporarily enable
 signals when control is passed to mono code from the threaded event loop
 and block them again afterwards. i.e. each time you call into mono from
 one of the threaded callbacks do a:

 {{{
 sigfillset(&mask);
 pthread_sigmask(SIG_UNBLOCK, &mask, &saved);
 ...
 /* call into mono here */
 ...
 pthread_sigmask(SIG_SETMASK, &saved, NULL);
 }}}

 Of course it would be more appropriate only to unblock the signals that
 mono really needs instead of all of them.

 I don't think it would be a good idea to merge the patch you suggested.
 While it be good for compatibility with mono it will most likely create
 problems in other software. Also, blocking all signals feels more correct
 to me. And finally, changing behaviour in the middle of everything seems
 like the worst solution to me.

-- 
Ticket URL: <http://pulseaudio.org/ticket/430#comment:1>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server