On Wed, Aug 29, 2001 at 05:21:00PM +0100, Daniel Barlow wrote:
> The good news: I have rudimentary co-operatively multitasked threads (need
> explicit calls to PROCESS-YIELD) running in SBCL Alpha. Special
> variables are dealt with using the same wind/unwind thing as CMUCL
> does, but we switch the stack pointers around instead of copying
> stacks. GC appears to work too.
> Signals don't, yet. Now, I believe that signal handlers installed in
> a thread should be called only if the relevant signal is received
> while that thread is running. (Would anyone else expect otherwise?)
> This is pretty simple in itself: just make interrupt_handlers
> per-thread data instead of global, and alter interrupt_handle_now
> as appropriate.
In an ideal world, I'd think that synchronous signals (e.g. SIGBUS
and, I think, SIGFPE) would be handled on a per-thread basis, while
asynchronous signals (e.g. SIGHUP) would be on a per-process basis.
But all I know about the practicalities of Unix signals and threads is
a dim memory of my POSIX threads book saying it's a really good idea
not to go there.
> What I'm not sure about the best way to handle is initialization and
> cleanup - in particular, why we're storing all the initial low-level
> handlers in old_low_level_signal_handler_states to restore at exit.
> Wouldn't it be just as effective to reset everything to SIG_DFL?
For all I know, yes. I think the save-the-old-states code may be left
over from my redoing CMU CL signal stuff without fully understanding it.
William Harold Newman <william.newman@...>
"Smooth duct tape: the mark of a true craftsman."
-- someone at Bettis Lab, quoted by my father
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C