[armedbear-devel] destroy-thread and unwind-protect

[Erik Huelsmann]

Hi all,

Reviving an old thread because of some private discussion with James which
spun off the LispWorks  users list.

The comment by Alessio below is one that I've been wondering about for
quite some time. What's our ThreadInterrupted "protocol"? Can we design
one, if we can't deduce one from code base?

I'm thinking about a protocol which works for the current code in the
libraries as well as all code that the compiler generates. Reading up on
the documentation for interrupts, it looks like we should be invoking
Thread.interrupted() in random places to see if we've been interrupted.
Presumably we need to do something with the interrupted information as
well, then though.

What more would there be to designing a protocol? We currently seem to be
executing lambda expressions which get pushed into a thread-local queue.
However, that's far from actually stopping the thread and destroying it.

Well?

Bye,


Erik.


On Mon, Oct 24, 2011 at 11:34 PM, Alessio Stalla <alessiostalla at gmail.com>wrote:

> On Sun, Oct 23, 2011 at 8:05 PM, James Lawrence <llmjjmll at gmail.com>
> wrote:
> >    (defun test-cleanup ()
> >      (let* ((cleanedp nil)
> >             (thread (threads:make-thread
> >                      (lambda ()
> >                        (unwind-protect (sleep 999)
> >                          (setf cleanedp t))))))
> >        (sleep 0.5)
> >        (threads:destroy-thread thread)
> >        (sleep 0.5)
> >        cleanedp))
> >
> >    (test-cleanup)
> >
> > ABCL-1.0.0 and ABCL-0.27.0 return NIL.
> >
> > Other implementations I tested all return T -- Allegro, Clozure,
> > LispWorks, SBCL (changing "threads" to "bordeaux-threads").
> >
> > Of course this isn't a bug since ABCL is free to do what it wishes.
> > Does ABCL wish that?
>
> I don't think we should wish that. It's inconsistent not only with
> other Lisp implementations, but with Java thread semantics as well.
> The problems are two: first, that destroy-thread doesn't really
> destroy the thread, it just sets a flag, so the sleep is not aborted
> (when it ends, the next form is not evaluated and the thread just
> terminates); second, that sleep swallows the ThreadInterrupted
> exception anyway, so even if it were interrupted, the thread would
> then continue normally.
> I think thread-destroy should be reimplemented to call
> Thread.interrupt() and that we should properly handle
> InterruptedException as a Lisp condition.
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20120808/12ea4790/attachment.html>