Re: thread cancellation, take 2

[Julian Graham]

On 9/26/07, Ludovic Courtès <address@hidden> wrote:

> Anyway, as long as you have a reference to an object (including a thread
> object), you can use the relevant procedures to mutate it.  For
> instance, if my code passes a list to yours, I have no guarantee that
> your code won't call `set-car!' on it.
>
> Just to say that hiding the data doesn't solve this authorization
> problem, it just makes it less visible.
>
> Beside, it may be useful in some cases to assign a thread finalizer from
> outside the thread itself.

Okay.  Here's the latest revision of the patch:

* Changed the API as Ludovic suggests above -- push-thread-cleanup and
pop-thread-cleanup are now, respectively, set-thread-cleanup! and
thread-cleanup, and you can set and get to / from whatever thread you
want.

* Updated threads.test.

* Modified the behavior of cancel-thread to allow for canceling the
current thread.  This necessitated some changes to scmsigs, so that
the signal delivery thread could be notified to shut down -- not
cleanly closing the signal pipe was leaving the process in a zombie
state -- specifically, the addition of an extra mutex and a function
in scmsigs.c. Let me know if this is too sloppy; rationale is provided
in the comments.

* Also (I realize this is a bit unrelated) changed the behavior of
all-threads so that it doesn't include the signal delivery thread,
because nobody has any business messing with it. Exposed a pointer to
the delivery thread from of scmsigs.o. I hope this isn't too sloppy,
either.


Regards,
Julian

thread-cancellation.HEAD.patch
Description: Text Data