The key thing is that the OS thread with the VM is no longer running
nor needed. The intent of the cancellation handler is to discard the
VM entirely; it no longer needs to run at all. If it makes things less
opaque, imagine I didn't set async cancellation, and that ffi.C.pause
is the only path in the lua script. My understanding was the VMs are
fully isolated. Is this incorrect? Is there some unavoidable corruptable
shared state between VMs once running?
I am still fundamentally curious why the designated handler for
signal 32 was not invoked. It still fails even if synchronous.
This is after spending time actually substituting and instrumenting
the macro expansions for pthread_cleanup_{pop,push}.
There's an explanation somewhere here.
As far as tone: I tend to read words such as "big no no" as "Child! I
think you won't understand, and I'm to lazy to explain." It fits in the
same league as "you can't handle the truth." Avoid those. Always
treat the questioner as if he were an adult.
Whether or not cancellation is racy will depend on what the threads
are doing. Threads are indeed fragile things. One might reasonably
say we use them precisely for some of that fragility. (I.e. resources
are automatically shared.)
The example code was not intended as exemplary. It was chosen to
be as small as I could make it. As I pointed out, if I avoided the
busy loop, I'd not even need to make the interruption asyncronous.
It's the discrepancy between platforms that surprizes me.
--
Christopher Oliver <current.input.port@xxxxxxxxx>
