Re: thread cancellation, take 2

[Julian Graham]

> Thinking a bit more about it, maybe we could let users handle the list
> of handlers if needed.  That is, we'd have just
> `set-thread-cleanup-procedure!' (a two-argument procedure whose first
> arg is a thread) and `thread-cleanup-procedure' (a one-argument
> procedure); users who have cleanup code spread over several procedure
> would provide a procedure that iterates over such pieces of code.  That
> would keep Guile's built-in mechanisms minimal.
>
> What do you think?

Well, in the use case for the native pthread_cancel implementation, it
makes a lot of sense to treat the handler list as a stack.  That is,
you have something like:

[LOCK MUTEX 1]
pthread_cleanup_push([UNLOCK MUTEX 1])
[ ...CODE CONTAINING CANCELLATION POINTS... ]
[LOCK MUTEX 2]
pthread_cleanup_push([UNLOCK MUTEX 2])
[ ... ]
pthread_cleanup_pop()
[UNLOCK MUTEX 2]
[ ... ]
pthread_cleanup_pop()
[UNLOCK MUTEX 1]


What's useful about this is that you can have several resources at
different levels of nesting that need to be cleaned up at cancellation
time, but you only need to worry about pushing and popping handlers
within your own scope.  If people feel that managing the entire list
at once is more Scheme-y, though, I can change it.

> First, you'll need to assign copyright to the FSF so that we can
> incorporate your changes (I'll send you the relevant stuff off-line).
> Then, you need to make sure your code follows the GNU Standards as much
> as possible (a few comments follow).  Also, please add a few test cases
> to `threads.test' that exercise the new API.

Great -- I'll deal with the paperwork, add tests, and clean up the
code as you've suggested.  I'll send the revisions to you offline, if
that's okay.


Thanks,
Julian