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

Shiro Kawai shiro at lava.net
Wed Dec 15 12:17:14 PST 2004

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/

More information about the Gc mailing list