On 9/26/07, Ludovic Courtès 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