[Mono-bugs] [Bug 592981] UnixSignal.WaitAny not interrupted when exiting
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Thu Apr 1 13:58:35 EDT 2010
http://bugzilla.novell.com/show_bug.cgi?id=592981
http://bugzilla.novell.com/show_bug.cgi?id=592981#c1
Jonathan Pryor <jpryor at novell.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpryor at novell.com
--- Comment #1 from Jonathan Pryor <jpryor at novell.com> 2010-04-01 17:58:35 UTC ---
Not sure what an appropriate fix/response is for this...
The "lazy" response is to declare that it's up to the application to worry
about such things. The workaround is trivial: as part of your process exit
raise all appropriate signals, e.g. before your Environment.Exit(0) call insert
a call to Stdlib.raise(Signum.SIGHUP).
This "works", but isn't exactly ideal. I'd be all for it if this were what C
did, but I've been unable to reproduce the "hang" with a minimal C sample, so
it doesn't appear that this is due to pthreads...
Another "fix" would be to alter UnixSignal to install an additional
AppDomain.ProcessExit or AppDomain.DomainUnload event handler, which would call
Stdlib.raise() as part of process exit (former) or AppDomain shutdown (latter).
I'm not keen on this, as I'm not sure what ramifications this would have.
The fundamental problem is that I don't know why the runtime is "hanging" at
all here. Again, I'm unable to reproduce with a minimal C sample, and thus I'm
not sure why poll(2) is apparently preventing process shutdown...
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the mono-bugs
mailing list