Re: [clisp-list] with-timeout interaction with unwind-protect

[Vladimir T. <vtz...@gm...>]

On Thu, 19 Feb 2009 19:22:33 +0200, Don Cohen  
<don...@is...> wrote:
> Vladimir Tzankov writes:
>  > > > CALL-WITH-TIMEOUT and THREAD-INTERRUPT are "dangerous" functions  
> ...
> If I understand correctly, thread interrupt simply stops the thread.
> It does not cause cleanup forms to be executed.  I have no complaint
> about that."Don Cohen" <don...@is...>

More specifically: stops the thread, executes the function in it and  
resumes it. If the function performs non-local exit (not recommended - but  
this is the way thread-kill is implemented) - whatever handlers are  
established in the thread will be executed.

> With-timeout, on the other hand, causes an unwind back to the call on
> with-timeout.  This, in my opinion, should specifically not abandon
> cleanup forms.

It does not abandon them. All cleanup forms are executed with one  
exception. If the control at the time of the interrupt is in a cleanup  
form - it will not be executed till it's end. This will be the only  
affected cleanup form. I agree that it is not good - but again - if we  
wait for the cleanup form to finish - we may never interrupt the thread.

>  > > > should be used with care. They interrupt thread at points at  
> which GC
>  > > > is possible. However if at that time the thread holds some locks -
>  > > > surprising results may come.
> I guess the surprising results you have in mind are things like some
> thread still holding a lock after it has exited from the (with-lock ...).
> This is a good example of what I'd like to avoid.

Upon thread exit - all locks that belong to it are released and warning  
issued. Worse problem is when the thread does not exit but erronously  
keeps some locks. In this case thread-interrupt with mutex-unlock will be  
useful.

> First, it seems to me that even now, when you interrupt with ^C and
> do abort, you can find yourself back in an infinite loop due to
> cleanup forms.

Yes - but you can always issue second ^C.

> I don't think this is a bad thing.  In the debugger
> you at least have control over where you abort from.  On the other
> hand, we do want to give the user the ability to skip cleanup forms
> from the debugger.
>
> Again, I think it's important to separate the interrupt from the
> processing that is done afterward.  It's not clear to me at this point
> what exactly is done afterward in the with-timeout form.
>
> What do you think of this proposal:
> - there should be some way to determine that you're in a cleanup form
>   (the lisp implementation could implement unwind-protect as
>   if the cleanup forms were inside (let ((*in-cleanup* t)) ...))
> - there should be some way to react to leaving cleanup code, e.g.
>   we could imagine that it generates a signal that is normally
>   handled by doing nothing
> - there should be a similar way to react to interruption
>   (I hope this already generates such a signal and that with-timeout
>   is simply supplying a handler for it.)

The risk is never to be able to "timeout" thread blocked in cleanup thread.
In any case we have to keep cleanup forms interruptible by  
thread-interrupt - since there will be no other way even to kill threads.

> BTW, does anyone out there know what other lisp implementations that
> support threads do about this issue?


Vladimir