thread cancellation, take 2

[Julian Graham]

Hi Guilers,

  A while back I did some work on introducing a thread cancellation
API into Guile's thread code.  At the time, the thread refactor for
1.8 hadn't yet happened, and I didn't really know enough about Guile
internals to get anything working.  I came back to my code recently
and made another attempt to integrate it, and I STILL couldn't make it
work, but now at least I think I know the right questions to ask.

  What I had in mind for thread cancellation is a set of three
functions that mirrors the pthreads API: cancel-thread,
push-thread-cleanup, and pop-thread-cleanup (as with pthreads,
push-thread-cleanup and pop-thread-cleanup respectively add and remove
expressions to and from a stack that is evaluated at the time
cancel-thread is called).  My implementation involves installing a
real pthreads cancellation handler that manages evaluation of Scheme
cleanup handlers and some thread shutdown behavior (although most of
this is handled by the new on_thread_exit stuff).  The problem I'm
having comes, I think, when I try to evaluate the items on the cleanup
list -- because the cancellation handler stack is the result of a
non-local exit from Guile's normal execution, I think there's
something wrong with the state of the stack boundaries or registers
that makes the GC freak out (heap corruption, I think, leading to a
double free() somewhere down the road) when I do an eval in that
context (whether or not I'm in Guile mode).  So: Is there a way to
safely evaluate SCMs from C after a JMP into a weird context?  (I
imagine the on_thread_exit code is called in a similar state, but it
only superficially manipulates SCM values...)  I've tried explicitly
resetting the top and base pointers of the stack, as well as updating
the register window, but that didn't seem to help.

  (At the time I asked about this originally, Marius Vollmer suggested
that cancellation be implemented as a system-async -- I think that
approach leaves us with the same issues regarding the GC / stack,
especially now that Guile threads are isomorphic to pthreads.)

  On a related note, do you guys have any preferences as to the
behavior of cancel-thread?  The way I've got it now, joining threads
will receive the value of the final expression in the cleanup-handler
list as the "result" of the canceled thread.  Does that make sense?
Also, should the items in the cleanup-handlers list be S-exprs or
should I limit them to being thunks (kind of leaning toward the latter
right now...)?


Thanks,
Julian


P.S. Here's a link to the thread from when I first tried to do this:

http://lists.gnu.org/archive/html/guile-devel/2004-10/msg00075.html