On 9 November 2010 06:42, Levente Uzonyi <leves@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.