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

Manuel Serrano Manuel.Serrano at sophia.inria.fr
Tue Jan 18 21:17:49 PST 2005


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 think this functionality is not well-tested.  But I'm interested
> in making sure it works, especially since I think it's also the
> only reasonable way to get good performance if you have large
> numbers of threads blocked at most points.
> 
> The plan is to make this functionality available on other platforms,
> especially since the custom support for Solaris, AIX, and Irix will
> be replaced by the standard pthread support.
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)? 

Many thanks in advance.

-- 
Manuel



More information about the Gc mailing list