From: Vladimir T. <vtz...@gm...> - 2009-02-19 17:42:51
|
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 |