[Openmcl-devel] Unix signal handling

[Daniel Weinreb]

In this whole discussion, I am wondering whether there
is some potential confusion due to tacit conflation of
"Unix asynchronous signals" and "interrupting a
thread".  The latter could happen due to
process-interrupt being called, for example.

If so, then separating these two subjects might help
everyone understand better what the issues are.

For example:

Gary Byers wrote:
>
> CCL's GC moves lisp objects around in memory.  Functions are lisp 
> objects.
>
> So: some thread is minding its own business, running the function FOO.
>
> A signal is delivered to that thread when the PC is N bytes into FOO.
> The OS saves the state of the thread (the signal context) and executes
> the signal handler.  The GC runs and stops all other threads; 
I have two questions.

(1) Could the GC be made aware of the signal context involving
FOO and the signal handler? Very hypothetically: the GC looks
at the PC of the stack, and sees that it's in between X and Y,
which means that this thread is handling a Unix async signal.
Between X and Y there is some convention about how registers
are used and such so that the GC knows what it needs to know?

(2) Is there some way that running the GC could be deferred
while the stack is inside the interrupt handler?

The answer to the above might depend on whether (a)
after the async interrupt is delivered, the thread might
call some Lisp code, a la process-interrupt, versus
(b) when a Unix async signal arrives, the handler
just does some simple thing like set a bit in a
field, and then return; the bit is seen later by
the housekeeping thread or something.

Gary, you must end up answering questions like this
every few months and it must be rather tedious.  I
apologize about that.

-- Dan





  How did the GC start
running?  Is this because there are two threads, one of which has
just entered the signal handler, while the other has, for whatever
reason, started a GC?
> the
> thread in question is about to signal the semaphore.  The GC decides
> that memory would look better if #'FOO was moved somewhere.  It
> carefully updates all references to #'FOO and to PC values inside
> #'FOO on all stacks and in all signal contexts that it's aware of.
> (It's not aware of the signal context involving FOO and the signal
> handler.)
>
> The GC finishes its work and resumes all other threads.  The thread
> running the signal handler signals the semaphore and the handler function
> returns; the OS then restores the thread's state (register values, 
> mostly)
> to the values saved in the signal context.  Code resumes execution at
> an address where #'FOO used to be before the GC moved it.
>
> That's not good.
>
> The handler function itself is entirely well-behaved; it doesn't even 
> cons.
> (The GC is invoked in this scenario because some other thread 
> consed.)  The
> problem here has to do with the fact that there's this sort of magic 
> control
> transfer/state change from "running FOO" to "running a signal handler" 
> and
> there'll be another magic transition back to "running FOO", and the 
> interrupted
> state - the signal context - isn't visible to the GC.
>
> I hope that this makes sense.  There's a very real issue here; it's 
> certainly
> an obscure one, but it's not just hypothetical.
>
>>
>> rg
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel