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

Igor Stasenko siguctua at gmail.com
Mon Nov 8 22:33:23 UTC 2010


On 9 November 2010 00:05, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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
>

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.
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.

> 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.
>
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.


> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list