On a related note, if it's okay with everyone, I'd like to add a thread-exit function in the next revision of this patch -- we're just so close to SRFI-18 compatibility, and that would take us the last few steps, I think.
Unfortunately, it doesn't seem like calling pthread_exit doesn't seem to do the trick, at least not in the main REPL thread -- it puts the process into a zombie state. It works in threads spawned by the REPL, and it works when you call it in such a way that the REPL doesn't get started up (e.g., guile -c "(exit-thread)"). I suspect this has everything to do with the signal delivery thread, but I'm struggling with the rest. Why would the fact that the signal delivery thread is left listening on a closed pipe make the process into a zombie? Exiting the entire process seems to work, so I could check to see whether the calling thread is the only active thread and then call exit(thread->result) if it is, but that's rather inelegant. (Does it even make sense to let people exit the REPL thread?) Maybe we should mark certain special threads internally as being, for example, the REPL or the signal delivery thread, etc. Can someone shed some light? I feel stupid. On 9/24/07, Julian Graham <[EMAIL PROTECTED]> wrote: > > I find it more elegant to use closures to that end. I.e., when > > installing a handler, you'd write something like this: > > > > (let ((cleanup (thread-cleanup-procedure (current-thread)))) > > (set-thread-cleanup-procedure! (current-thread) > > (lambda () > > ;; invoke previous handler > > (if (procedure? cleanup) > > (cleanup)) > > ;; clean up... > > ))) > > > > There's a race here in case multiple threads try to change the cleanup > > procedure associated with that particular thread at the same time, but I > > suppose it is not an issue in practice. > > Fair enough, re: closures. But why should callers outside the current > thread be able to access that thread's cleanup handler procedure? > Maybe this isn't a realistic issue, but you could use this to "inject" > arbitrary code into a separate thread by setting the cleanup procedure > and immediately canceling the thread. Why not treat the handler as > thread-specific data? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
