[squeak-dev] Re: [Pharo-project] #ensure: issues

Levente Uzonyi leves at elte.hu
Thu Mar 4 02:02:13 UTC 2010


On Wed, 3 Mar 2010, Andreas Raab wrote:

> On 3/3/2010 5:44 PM, Levente Uzonyi wrote:
>> Here's a simple example (replace file with any external resource):
>> My process opened a file, a termination block will close it if it's
>> evaluated. If I send #terminate to the process I expect my file to be
>> closed, so I won't leak a file descriptor.
>> If the file can't be closed (aka the termination block raised an error)
>> then there's a serious problem. It doesn't really matter what happens then.
>> 
>> But I don't have to try to convince you anymore, because Andreas is
>> about to solve the issue.
>
> Just FYI, the reason why you're not getting through to Igor is because you're 
> arguing the case from the perspective of a non-well-behaved termination block 
> which is a lost cause. There simply are no assurances for that, Igor is

It must be my bad english, because I don't really care about 
non-well-behaved termination blocks.

> correct on that. But that shouldn't stop us trying to support well-behaved 
> blocks properly. Because if we don't then ensure becomes entirely random. Or

That's exactly what I'd like to happen.


Levente

> can anyone here explain why it would be reasonable to expect that this 
> version works:
>
> p := [[Processor yield] ensure:[Transcript show: 'finished']] fork.
> Processor yield.
> p terminate.
>
> but this one doesn't:
>
> p := [[] ensure:[Processor yield. Transcript show: 'finished']] fork.
> Processor yield.
> p terminate.
>
> (we're using yield here to denote any kind of process switch) If the only 
> thing that determines whether an ensure block is executed is a process 
> switch, then we basically have random, non-predictable unwind handling. Which 
> is a problem that is entirely unrelated to whether the unwind block is itself 
> well-behaved or not.
>
> Cheers,
>  - Andreas
>
>



More information about the Squeak-dev mailing list