[Openmcl-devel] async signals

[Gary Byers]

On Thu, 1 Sep 2005, [iso-8859-1] Gábor Melis wrote:

> Hello

I'll try to take a look at the documents you referenced sometimes
soon.

Every time that I've tried to convince myself that unwinding should
ignore or defer asynchronous interrupts - and have convinced myself
that I understood just when unwinding started, when it ended, and
when it was prematurely exited - I convince myself that that's
undesirable and less tractable than it'd first seemed.  I'm currently
on the latter end of that pendulum, but it was swinging the other
way a few weeks ago.

I'll try to read the material you referred to before rambling further.

> I've read that openmcl checks for pending interrupts at safe-points.

Where, out of curiousity, did you read this ?  (It's not true, but it
used to be.  Lisp code can interrupted basically at any time (unless
WITHOUT-INTERRUPTS is in effect.)  The "internals" documentation on
the website is several years old and is maybe 50% accurate; I think
that there's a disclaimer to that effect somewher

> Where are these safe points? Do they help with issues above?

There used to be instruction sequences that generated conditional
traps on function entry and at loop heads.  (This was basically
used to drive the old cooperative scheduler; something similar
still happens on exit from WITHOUT-INTERRUPTS and on return from
FF-CALL, but that's basically just a mechanism for dealing with
deferred interrupts.)

There was certainly code that knew that it was uninterruptible
because it wasn't doing any function calls or backward branches.
I don't think that that code helped with much of anything and
it tended to obscure its intent, which was usually some combination
of having exclusive access to some shared resource and being
uninterruptible.

There may still be some such code.

>
> Thanks, Gábor Melis
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>