[Gc] Signal handlers and GC-Boehm's signals

Boehm, Hans hans.boehm at hp.com
Thu Jan 20 17:54:10 PST 2005

> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Manuel Serrano
> Sent: Tuesday, January 18, 2005 9:18 PM
> Hello Hans,
> I would like to ask you some clarifications about a mail you 
> wrote recently:
> > I believe that for platforms supported by the standard 
> pthread support
> > (which for 6.3 excludes Solaris, AIX, Irix, and Cygwin), you should
> > also be able to call GC_start_blocking() before such a call, and
> > call GC_end_blocking() after the call, with no pointer manipulations
> > in between.  This basically gets the thread to cooperate in any
> > collection attempt by the GC.  Hence the signal is no 
> longer required,
> > and should no longer be sent.
> > ...
> I'm not sure to understand correctly the implication of this. 
> Could you
> confirm that the following understanding is correct or not? 
> Thanks in advance.
> In a multithreaded context, any invocation of a system function that
> could be interrupted because of the GC signals emissions, should be
> nested inside a GC_start_blocking and GC_end_blocking pair. 
> For instance, a
> "good" programming should look like:
>    GC_start_blocking();
>    ... select( ... ) ...
>    GC_stop_blocking();
> Is this correct?
> I don't understand the implication of GC_start_blocking. What happens
> if one thread calls GC_start_blocking() but never calls 
> GC_stop_blocking()
> (for instance because the select invocation in the previous 
> example never
> returns)? 
GC_start_blocking ensures that stack pointer(s) visible to the GC is
current, and notifies the GC that is, for all intents and purposes,
already stopped.  Thus it no longer needs a signal.

GC_stop_blocking() tells the collector that the thread may manipulate
pointers again.

Forgetting to call GC_stop_blocking() would be bad.  Having the thread
blocked indefinitely, and hence never calling GC_stop_blocking()
should be OK.

Thinking about this some more, I don't completely believe the code.
There's probably an issue if the client thread calls GC_start_blocking,
but needs to spill some callee-save pointer-containing registers to
the stack just before the blocking system call.  That's unlikely,
but I should think about this some more.

> Many thanks in advance.
> -- 
> Manuel
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list