[Gc] Signal handlers and GC-Boehm's signals
hans.boehm at hp.com
Wed Dec 15 13:39:33 PST 2004
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.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Shiro Kawai
> Sent: Wednesday, December 15, 2004 12:17 PM
> To: Stephane.Epardaud at sophia.inria.fr
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Signal handlers and GC-Boehm's signals
> I'm using another Scheme implementation (Gauche) with Boehm GC,
> and using this strategy:
> Basically, I set a signal handler for all catchable signals
> except that Boehm GC uses. The handler just queues the signal
> into a per-thread structure and return.
> All system calls are called with a wrapper, which checks
> if the system call returns EINTR, and process the queued
> signals, then restart the syscall.
> I don't know the internals of Bigloo, but I suspect you can't
> do much within the C signal handler anyway, so you may need
> some queueing mechanism.
> From: Stephane Epardaud <Stephane.Epardaud at sophia.inria.fr>
> Subject: [Gc] Signal handlers and GC-Boehm's signals
> Date: Mon, 13 Dec 2004 14:48:38 +0100
> > Hello,
> > I'm using Bigloo (the Scheme->C compiler) under Linux (2.6
> with NPTL) which uses
> > the Boehm GC.
> > I have a question regarding signals. I understand your GC
> uses SIGXCPU and
> > SIGPWR to stop all pthreads when it wants to do a GC. I
> have a problem when one
> > of my pthreads is doing a blocking "select" system call.
> When the GC stops it
> > and restarts it, "select" returns with an error of -1 and
> errno set to EINTR
> > (which is the proper behaviour as far as I know).
> > Now the question is, how do I know whether my system call
> was interrupted by the
> > GC and I can retry my system call, or if that was a signal
> I should not have
> > ignored and treat it as an error ?
> > I have this problem at different places ("accept", "send"
> for ex.), and I cannot
> > find a way to tell whether I caught a signal like SIGSTOP
> or SIGPIPE, or if it
> > was just the GC and all is fine.
> > I tried blocking SIGXCPU, setting up a signal handler for
> SIGXCPU (that would
> > set a flag to 1 and call GC_suspend_handler when the signal
> would be caught),
> > and entering pselect (which would unblock SIGXCPU) and
> checking whether the INTR
> > error occured with my flag set to 1 and in that case,
> retry. But with no luck,
> > it seems these signals handlers should not be messed with.
> > Now on the other side I'm also blocked checking for SIGPIPE
> because there
> > already is a signal handler for it and it's a nightmare to
> chain signal handlers.
> > Do you have any advice as to how to detect an EINTR error
> was caused by a GC
> > operation ?
> > Thanks a lot.
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc