On 11/8/2010 1:22 PM, Igor Stasenko wrote:
> Currently such example will work only in Pharo, and only if ensure
> block evaluated within same active process (which is not, if you
> terminating this process from other process).

Well, then don't write code like that :-) Seriously, your code example 
seems broken. First, in the case of:

[
  " init session here "
[ ... do something ... ] ensure: [ self session close]
] fork

it will function correctly since your session is initialized *within* 
the fork not outside of it, thus Processor activeProcess is the child 
process, not the parent process. But even if we leave that out, I'd 
expect your code to read, e.g.,

  " init session here "
forkedSession := self session.
[
self session: forkedSession.
[ ... do something ... ] ensure: [ self session close]
] fork

So I'd say that the fault is solely in your code.

FWIW, the only realistic alternative that I could see is if the TLS 
either implements some sort of inheritance for the environment lookup 
(i.e., look up locally and if locally undefined traverse through parent 
processes) or copies all the variables into a newly forked process. Both 
approaches raise some very nasty concurrency issues which is why I 
prefer the simple (non-)solution we have today. A bug like in the code 
above is easy to find and to fix as it is completely reproducible. 
Contrary to which concurrent access to the environment dicitionary is 
not, and even if it is serialized you still need to make sure the access 
to the contents is serialized as well.

Cheers,
   - Andreas