[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Re: Delay in a Process and sending #terminate

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: 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]