[Gc] Signal handlers and GC-Boehm's signals
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
> 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
More information about the Gc