Re: thread cancellation, take 2

[Julian Graham]

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 <address@hidden> 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?