On 9 November 2010 02:02, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 11/8/2010 2:33 PM, Igor Stasenko wrote:
>>
>> On 9 November 2010 00:05, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>>
>>>  " init session here "
>>> forkedSession := self session.
>>> [
>>> self session: forkedSession.
>>> [ ... do something ... ] ensure: [ self session close]
>>> ] fork
>>>
>>
>> hmm.. i don't think that session initialization should always take
>> place within same process where it is used. I could pass already
>> initialized session, and then " init session here " is only to put it
>> into process environment var.
>
> Sure. But then it's initialized within the correct scope so your ensure
> block will work correctly. (fwiw, at this point I'm a bit confused about
> what you're trying to do and how it wouldn't work currently; can you perhaps
> write a simple test that illustrates the problem?)
>

Suppose you have a domain object which provides following ways to
access the session:

session: forkedSession
    Processor activeProcess environmentAt: #session put: forkedSession

session
    ^ Processor activeProcess environmentAt: #session


now, here what i'd like to write:

| session |

 session := MySession new .
 session initialize blabla.

"good fork"
good := [
   self session: session.
  [ self process stuff ] ensure: [ session close ]
] newProcess.

good resume.
1 minute asDelay wait.
good terminate.
self assert: (session isClosed).

In the above case, everything is ok: session object is passed in 'session' temp
and visible inside ensure block directly, so, no matter what may
happen (process termination),
it is guaranteed that session will be closed at the end.

"bad fork"

session := MySession new .
session initialize blabla.

bad := [
   self session: session.
  [ self process stuff ] ensure: [ self session close ]
] newProcess.

bad resume.
1 minute asDelay wait.
bad terminate.
self assert: (session isClosed).


In this case, a session is accessed indirectly, through process specific state.
And test might fail or not, depending if process was already
terminated before sending #terminate,
or its still running.

The 'bad fork' illustrates that one should not attempt to access a
process specific state in ensure blocks,
because during process termination, stack unwinding is performed by
other process, which could have different session object,
or don't have it at all.

This is simple, of course, to implement session finalization without
using process spefic state. But now consider that session has not only
#close method, but allows doing something more userful, like:

self session backupStuff.
[   .. do something.. ] ensure: [ self session restoreStuff ].

And again, same problem: unless you have a direct reference to session
object, you can't do it.
Not with using process-specific state, because it is flawed.

In other words, anything which may want to access to a
process-specific state, like:

[ ... ... ] ensure: [ (Processor activeProcess environmentAt: #foo)
doSomething ]

have no guarantees to work correctly in all cases.

This defeats a purpose of process-specific state, because you can't
rely on it for building a reliable stuff.


>> I want to associate a certain state with process (which is a session).
>> So, then any domain object could access it by using 'self session',
>> without need of using exception mechanism (like seaside does with
>> WADynamicVariable), or even worse, keep a direct reference to it.
>>
>> For instance, when you creating a new process on a server for each
>> client socket connection, this is
>> logical to associate that process with a session.
>
> I'm not so sure about that :-) But yes, it's something that could be done.
> Though, again I would expect that the initialization of the session global
> happens within the fork, thus all of the above should work fine.
>

i don't see how initialization related to problem, that
process-specific state are not accessible for all cases
and all stages of process life, as seen by developer, when he using
#ensure: blocks.

>> i din't considered about parent/child relationship between processes
>> (like unix style processes).
>> It opens some interesting perspectives, but i don't think we need such
>> relationship so much,
>> because its easy to share state between processes without such
>> 'unixish' ad-hoc composition.
>
> Agreed.
>
> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.