This is the mail archive of the
guile@cygnus.com
mailing list for the Guile project.
Re: Guile and alarm(2)
- To: forcer@mindless.com
- Subject: Re: Guile and alarm(2)
- From: Gary Houston <ghouston@easynet.co.uk>
- Date: 20 Jul 1999 17:58:40 -0000
- CC: guile@sourceware.cygnus.com
- References: <199907182206.AAA28242@forcix.roof.lan>
| Hmm..
| What happens when Guile is in the middle of some processing
| (gh_eval_str, or something) and the process is interrupted by a
| signal, e.g. SIGALRM?
|
| The reason i'm asking this is that in Apache, one can set hard
| timeouts, which work by calling alarm(2), and aborting all
| processing. I'm sure that at least in those areas who are usually
| secured by SCM_DEFER_INTS / SCM_ALLOW_INTS, such an interrupt
| (without resumeing the original processing) would cause alot of
| trouble. Right?
|
| If so, how can i "protect" those functions, if at all? I have
| similar functions, ap_block_alarms() / ap_unblock_alarms(), which
| i could call, but do i really have to wrap every scm_* and gh_*
| call with those? I hope not :)
|
| Any ideas on how to solve this would be appreciated,
Perhaps you could install a SIGALRM handler from Guile each time it's
called by Apache and remove it before returning? The Guile handler
wouldn't be called during a critical section (in that case take_signal
just sets a flag and the handler gets called when INTS are ALLOWED.)
The Scheme handler could probably just restore the Apache handler and
raise SIGALRM again.