[squeak-dev] Re: Process-specific state broken and uncomplete
andreas.raab at gmx.de
Tue Nov 9 00:02:34 UTC 2010
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?)
> 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
> 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.
More information about the Squeak-dev