|
From: | Paolo Bonzini |
Subject: | [Help-smalltalk] Re: Delay in a Process and sending #terminate |
Date: | Mon, 20 Dec 2010 11:22:45 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6 |
On 12/20/2010 11:06 AM, Holger Hans Peter Freyther wrote:
On 12/18/2010 08:00 PM, Paolo Bonzini wrote:Aha, I could now reproduce what you meant, but it's not a bug. The problem is that if you're already in the #ensure: block, or in the #critical: block, #terminate will be able to unwind it. So, #ensure: is fundamentally incompatible with #terminate (at least as it is implemented now). I have to think more about it.I assume it is the same for sending any message? I have moved from terminate to send a simple Notification/Exception. But as it is mostly implemented the same way, I face the same issue?
I think ProcessBeingTerminated is different, but it has the problem that it is more akin to #ifCurtailed: than to #ensure:.
It would be interesting to see what other dialects do. But it is better to think of #terminate as a very bad idea in general :) and rethink processes to implement *interruption* rather than termination.
Another possibility in your case is to implement the processes collection using a wrapper, so that iteration will filter out processes that have terminated.
I'm also thinking of moving #queueInterrupt: to a primitive or something like that so that it's not preemptable/interruptible. This means that instead of removing itself from the collection, a terminating process could *atomically* ask another process to do the removal.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |