[Pharo-project] Process-specific state broken and uncomplete
Hello, i just found that Squeak images Process class contains unused ivars: island env in Pharo image, env ivar is used for holding a process-specific state, which is convenient, so one could use: Processor activeProcess environmentAt: put:... but in Squeak image there is even no such methods. There are also some caveats with such thing: during process termination, Processor activeProcess could point to different process, and so, accessing to process environment may lead to error(s). To avoid issues like these, the process termination action (stack unwinding) should be always performed only for active process. One of a trick i think, is to replace the suspendedContext with own context, and then activate given process in order to unwind its stack etc. Another way is to remember environment somewhere else during process termination, and use different method to access it i.e. instead of: Processor activeProcess environmentAt: use self processEnvironmentAt: where #processEnvironmentAt: is implemented in Object class, and can handle termination gracefully. But i think replacing suspendedContext is more generic. What you think? -- Best regards, Igor Stasenko AKA sig.
On Mon, 8 Nov 2010, Igor Stasenko wrote:
Hello,
i just found that Squeak images Process class contains unused ivars: island env
IIRC those were added by Matthew Fulmer to support ProcessSpecific _and_ Cobalt. The idea is that the two can be used together this way, because the definition of Process doesn't have to be changed.
in Pharo image, env ivar is used for holding a process-specific state, which is convenient, so one could use: Processor activeProcess environmentAt: put:...
but in Squeak image there is even no such methods.
So they integrated the full ProcessSpecific package. Is it a problem that you have to load it into Squeak? Levente
There are also some caveats with such thing: during process termination, Processor activeProcess could point to different process, and so, accessing to process environment may lead to error(s).
To avoid issues like these, the process termination action (stack unwinding) should be always performed only for active process. One of a trick i think, is to replace the suspendedContext with own context, and then activate given process in order to unwind its stack etc.
Another way is to remember environment somewhere else during process termination, and use different method to access it i.e. instead of: Processor activeProcess environmentAt: use self processEnvironmentAt:
where #processEnvironmentAt: is implemented in Object class, and can handle termination gracefully.
But i think replacing suspendedContext is more generic. What you think?
-- Best regards, Igor Stasenko AKA sig.
On 9 November 2010 03:31, Levente Uzonyi <leves@elte.hu> wrote:
On Mon, 8 Nov 2010, Igor Stasenko wrote:
Hello,
i just found that Squeak images Process class contains unused ivars: island env
IIRC those were added by Matthew Fulmer to support ProcessSpecific _and_ Cobalt. The idea is that the two can be used together this way, because the definition of Process doesn't have to be changed.
Sure.
in Pharo image, env ivar is used for holding a process-specific state, which is convenient, so one could use: Processor activeProcess environmentAt: put:...
but in Squeak image there is even no such methods.
So they integrated the full ProcessSpecific package. Is it a problem that you have to load it into Squeak?
So, its a separate package, except that ivars already there.. Strange choice. Maybe it worth mentioning then in Process comment that these vars are there for purpose? Otherwise someone may attempt to remove them :)
Levente
There are also some caveats with such thing: during process termination, Processor activeProcess could point to different process, and so, accessing to process environment may lead to error(s).
To avoid issues like these, the process termination action (stack unwinding) should be always performed only for active process. One of a trick i think, is to replace the suspendedContext with own context, and then activate given process in order to unwind its stack etc.
Another way is to remember environment somewhere else during process termination, and use different method to access it i.e. instead of: Processor activeProcess environmentAt: use self processEnvironmentAt:
where #processEnvironmentAt: is implemented in Object class, and can handle termination gracefully.
But i think replacing suspendedContext is more generic. What you think?
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Tue, 9 Nov 2010, Igor Stasenko wrote:
On 9 November 2010 03:31, Levente Uzonyi <leves@elte.hu> wrote:
snip
So they integrated the full ProcessSpecific package. Is it a problem that you have to load it into Squeak?
So, its a separate package, except that ivars already there..
Yes, it's on SqueakSource.
Strange choice. Maybe it worth mentioning then in Process comment that these vars are there for purpose? Otherwise someone may attempt to remove them :)
Good idea. Levente snip
On 08.11.2010 06:39, Igor Stasenko wrote:
Hello,
i just found that Squeak images Process class contains unused ivars: island env
in Pharo image, env ivar is used for holding a process-specific state, which is convenient, so one could use: Processor activeProcess environmentAt: put:...
but in Squeak image there is even no such methods.
There are also some caveats with such thing: during process termination, Processor activeProcess could point to different process, and so, accessing to process environment may lead to error(s).
To avoid issues like these, the process termination action (stack unwinding) should be always performed only for active process. One of a trick i think, is to replace the suspendedContext with own context, and then activate given process in order to unwind its stack etc.
Another way is to remember environment somewhere else during process termination, and use different method to access it i.e. instead of: Processor activeProcess environmentAt: use self processEnvironmentAt:
where #processEnvironmentAt: is implemented in Object class, and can handle termination gracefully.
But i think replacing suspendedContext is more generic. What you think?
Not so convinced. Fast thread locals are important and a Symbol lookup in an IdentityDictionary is pretty fast. And polluting Object with stuff that doesn't belong there isn't a very convincing alternative to me. Cheers PHilippe
On 9 November 2010 08:06, Philippe Marschall <kustos@gmx.net> wrote:
On 08.11.2010 06:39, Igor Stasenko wrote:
Hello,
i just found that Squeak images Process class contains unused ivars: island env
in Pharo image, env ivar is used for holding a process-specific state, which is convenient, so one could use: Processor activeProcess environmentAt: put:...
but in Squeak image there is even no such methods.
There are also some caveats with such thing: during process termination, Processor activeProcess could point to different process, and so, accessing to process environment may lead to error(s).
To avoid issues like these, the process termination action (stack unwinding) should be always performed only for active process. One of a trick i think, is to replace the suspendedContext with own context, and then activate given process in order to unwind its stack etc.
Another way is to remember environment somewhere else during process termination, and use different method to access it i.e. instead of: Processor activeProcess environmentAt: use self processEnvironmentAt:
where #processEnvironmentAt: is implemented in Object class, and can handle termination gracefully.
But i think replacing suspendedContext is more generic. What you think?
Not so convinced. Fast thread locals are important and a Symbol lookup in an IdentityDictionary is pretty fast. And polluting Object with stuff that doesn't belong there isn't a very convincing alternative to me.
does that means that you prefer to replace suspendedContext?
Cheers PHilippe
-- Best regards, Igor Stasenko AKA sig.
On 09.11.2010 07:17, Igor Stasenko wrote:
On 9 November 2010 08:06, Philippe Marschall <kustos@gmx.net> wrote:
On 08.11.2010 06:39, Igor Stasenko wrote:
Hello,
i just found that Squeak images Process class contains unused ivars: island env
in Pharo image, env ivar is used for holding a process-specific state, which is convenient, so one could use: Processor activeProcess environmentAt: put:...
but in Squeak image there is even no such methods.
There are also some caveats with such thing: during process termination, Processor activeProcess could point to different process, and so, accessing to process environment may lead to error(s).
To avoid issues like these, the process termination action (stack unwinding) should be always performed only for active process. One of a trick i think, is to replace the suspendedContext with own context, and then activate given process in order to unwind its stack etc.
Another way is to remember environment somewhere else during process termination, and use different method to access it i.e. instead of: Processor activeProcess environmentAt: use self processEnvironmentAt:
where #processEnvironmentAt: is implemented in Object class, and can handle termination gracefully.
But i think replacing suspendedContext is more generic. What you think?
Not so convinced. Fast thread locals are important and a Symbol lookup in an IdentityDictionary is pretty fast. And polluting Object with stuff that doesn't belong there isn't a very convincing alternative to me.
does that means that you prefer to replace suspendedContext?
I prefer to keep env. I can live with the current limitations. Process termination is just so tricky (as other languages found out as well) that it's IMHO better to simply avoid it (like finalization) instead of coming up with some clever hacks to fix it. VW for example has three or four methods to terminate a process. Cheers Philippe
participants (3)
-
Igor Stasenko -
Levente Uzonyi -
Philippe Marschall