[squeak-dev] Re: System and user processe

Max Leske maxleske at gmail.com
Tue Jun 21 13:46:37 UTC 2016


>> Message: 17
>> Date: Tue, 21 Jun 2016 00:33:17 -0700 (PDT)
>> From: "marcel.taeumel" <Marcel.Taeumel at hpi.de>
>> Subject: [squeak-dev] Re: [Vm-dev] System and user processes
>> To: squeak-dev at lists.squeakfoundation.org
>> Message-ID: <1466494397918-4902025.post at n4.nabble.com>
>> Content-Type: text/plain; charset=UTF-8
>> 
>> Chris Muller-3 wrote
>> Hi Max, I had a similar idea, and made a ClientProcess class.  Its
>> primary purpose is to provide a nice wrapping API for *users* to
>> manage their "background running tasks" (i.e., #start, #stop, #pause,
>> #resume, #progress, #priority adjustment), as well as a nice API for
>> *developers* to report its progress via a simple signaling mechanism,
>> which also gives the user all the performance stats for "free" too
>> like #unitsCompleted, #runningTime, #ratePerSecond, #remainingTime,
>> etc.
>> 
>> On Sun, Jun 19, 2016 at 4:03 AM, Max Leske &lt;
>> 
>> maxleske@
>> 
>> &gt; wrote:
>> 
>> Hi,
>> 
>> In Pharo and Squeak we have no separation between processes that belong
>> to the IDE, tools etc. and processes that are spawned as part of an
>> application. I’d like to know your opinion on the following (rough) idea:
>> 
>> 1. We introduce two subclasses of Process: SystemProcess and UserProcess
>> 2. We define #isSystemProcess and #isUserProcess
>> 3. We introduce #newSystemProcess and #newUserProcess
>> 4. We deprecate #newProcess and delegate to #newUserProcess (thereby
>> modifying all users of #forkXXX to yield instances of UserProcess)
>> 
>> Of the following I’m less sure:
>> 5. We introduce #forkSystemProcess et. al
>> 
>> I’ve tried this out in Pharo 6 and there seem to be no problems with the
>> VM. The benefit would be improved separation between system and user
>> space. It would allow us to implement stuff for processes in general
>> (e.g. for the debugger) which we do not want to affect system processes
>> like the UI process or the background process. One concrete example: the
>> process browser could hide all system processes and make them visible on
>> demand (that would greatly improve the view because you can now better
>> find your own processes).
>> 
>> 
>> I’m looking forward to your comments.
>> 
>> Cheers,
>> Max
> 
> Hi Chris,
> 
> Hmm... I would implement such an API rather via composition than
> inheritance. Such a task does not necessarily have to run in the same image
> but could also be accomplished on another machine. OSProcess has RemoteTask
> for this. Inheritance would make things complicated once one would decide to
> not carry out the computation as a Squeak process.
> 
> I do like Tony's idea of process groups. We could think this one step
> further an add multiple tags (symbols?) to processes to support
> fine-granular or cross-cutting classifications. Tools like the process
> browser could show these tags, group by them, etc. There could be tags to
> identify processes that would stop working once you close the Squeak image
> (e.g. "not resumable")... Hmmm... Application developers could use tags to
> provide hints for other developers and users.
> 
> Best,
> Marcel


Good point. Inheritance is nice but as for our infamous stream hierarchy processes would probably need to be grouped by different traits. But I think that groups and tags may be two different things. Tony’s “current process group” for instance would have to implemented as a special tag already, unless a new process simply inherited all tags.

In Pharo (I don’t know about Squeak) we now have a session manager that can be asked if the current session has changed, i.e. whether the image has been restarted. Now, instead of checking in with the session manager explicitly I could use a “session dependant” process, which terminates when the session changes.

Cheers,
Max



More information about the Squeak-dev mailing list