[Pharo-project] [squeak-dev] Re: Process-specific state broken and uncomplete

Igor Stasenko siguctua at gmail.com
Tue Nov 9 06:33:28 CET 2010


On 9 November 2010 06:42, Levente Uzonyi <leves at elte.hu> wrote:
> On Tue, 9 Nov 2010, Igor Stasenko wrote:
>
> snip
>
>>
>> No, you can't. I feel sorry for you :)
>>
>> A #useSession:during: using ensure, and of course it will work
>> correctly, because you not accessing session via
>> process-specific storage. This is illustrated by my "good fork" example.
>
> Erm, no. In both of your examples the session wasn't aquired by the forked
> process. It was available via a variable. If you aquire the session _in_ the
> forked process _from_ the session store, then the #ensure: block in the
> session store will be able to retrieve it.
>

this doesn't changes anything. The point is that once you accessing
_any_ process-specific state in ensure
block, you're in trouble. And of course, if you capturing such state
before entering ensure block, you are safe.
But this not always an option.

>>
>> now replace #doSomething with this:
>>
>> [ 1 year asDelay wait ] ensure: [
>>  self assert:  (Processor activeProcess environmentAt: #session) notNil ]
>>
>> and then terminate a process which running your fork.
>
> Replaced (in theory) and terminated. What will happen? This assertion in
> this #ensure: block will fail, but the session will be retrieved properly by
> the session store's unwind block.
>
> So you can use process local variables, but you shouldn't access them during
> unwinding (#ensure:, #ifCurtailed:, whatever). This is possible as I showed
> it in my example.
>
i didn't said this is not possible.

>>
>> In attachment you'll find a test, which shows the problem (i using
>> tests from Pharo image).
>
> The test fails, because you're accessing a process local variable in an
> unwind block, which you shouldn't do.
>

Why i shouldn't?
Give me the reasons why. ("because it works that way" is not a good answer ;)
It sounds like you feel completely happy with current status quo, and
don't want to address that problem.

I don't know how else to convince you that this is wrong.
Suppose you wrote a library, which using a process-local state, buried
somewhere deeply.
Users of your library might even be not aware of it, because they will
be using a higher-level api.
A developer who writes own code, sure thing, thinks that he is free to
use #ensure: #ifCurtailed:
whereever he needs to, isnt?
But with stuff like that, you putting him in the position, that he
should be aware of such subtle nuances, and be very careful about
using your api inside ensure blocks.

This is really beyond my understanding. Why we should not provide a
consistent API instead?

>
> Levente
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list