[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
|