[Gc] About signals

Boehm, Hans hans.boehm at hp.com
Thu Sep 24 12:26:13 PDT 2009


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Juan Jose 
> Garcia-Ripoll
> Sent: Thursday, September 24, 2009 10:48 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] About signals
> Would it be possible to create an API for querying / setting 
> the signal codes that are used for suspeding / resuming 
> threads? This seems to vary a lot from platform to platform 
> and in ECL we need to block signals, handling asynchronous 
> ones in separate threads, and also provide a suspend / resume 
> feature. Right now I already detected problems with FreeBSD 
> that I am solving with hacks on our side.
> Juanjo
I don't immediately see why not, except that someone needs to generate the patch.  Currently SIG_SUSPEND and SIG_THR_RESTART are determined at compile time, but there's probably not a good reason for that.  There may be good reasons not to change the current (platform-dependent) defaults, since people are used to them when debugging.  (Some thought did go into them at some point, but the arguments for the current values are probably long obsolete on most platforms, as the mumber of available signals grew, etc.)

I think Mono ended up using the GC thread suspension mechanisms for thread suspension in general.  That's another possible direction.


More information about the Gc mailing list