[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