[Gc] Signal handlers and GC-Boehm's signals
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:
> ... select( ... ) ...
> 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
> (for instance because the select invocation in the previous
> example never
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
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.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc