[Mono-list] Signals and native callbacks

Jay L. T. Cornwall jay at jcornwall.me.uk
Sat Dec 20 09:49:57 EST 2008


Hi,

As explained here Mono has some unusual signal requirements:

http://www.mono-project.com/Debugging#Debugging_with_GDB

I found this to be problematic when interfacing with the native 
PulseAudio library through P/Invoke. PulseAudio's "threaded mainloop" 
API creates a pthread with a fully SIG_BLOCK'd mask to avoid interfering 
with client processes. Callbacks are then made into managed code to, 
e.g. notify state changes and request audio data for playback.

During these callbacks (or just before/after, I am unsure) an unrelated 
Mono thread performing a DNS lookup consistently froze up. By adding a 
native interception layer to the callback which called:

sigemptyset(&monoSigs);
sigaddset(&monoSigs, SIGXCPU);
sigaddset(&monoSigs, 33);
sigaddset(&monoSigs, 35);
sigaddset(&monoSigs, SIGPWR);
pthread_sigmask(SIG_UNBLOCK, &monoSigs, NULL);

Correct operation was restored. This is the solution I have gone with, 
for now but it is of course highly confusing to the P/Invoke programmer 
and (as far as I know) an undocumented requirement.

Would you agree that Mono is in the wrong here by assuming that any 
native thread entering the runtime has a desired signal mask? Or am I 
exceeding the specification in attempting to do this in the first place?

Thanks,

-- 
Jay L. T. Cornwall
http://www.jcornwall.me.uk/


More information about the Mono-list mailing list