On Mon, 2015-10-19 at 09:31 +0100, Julien Isorce wrote: > Thx for the review. Indeed I double checked and prctl should be > blocked. It seems in chromium gpu process and plugin process, they > enable it that why we did too. Though there is a todo saying to block > it :) > In our case we can directly block it. > > For my patch it means the condition "prctl(PR_GET_SECCOMP" should go > away and the todo too. > > I am also wondering why pulseaudio block signals > "pthread_sigmask(SIG_BLOCK, &mask, NULL);" > > AFAIK glib does not do that. Also is pa_threaded_mainloop_start > called in pa sever too ? Maybe it should be applied to the server > only. Worth to mention that pthread_sigmask(SIG_BLOCK, &mask, NULL); > has last been touched in 2006. I am not saying this a reason at all > but just in case :) Looks like the idea is to ignore signals from the mainloop thread, and let the main application thread deal with them. Makes sense in the audio thread context so we don't get unexpectedly blocked and miss playing or capturing samples. Cheers, Arun
