Message: 17 Date: Tue, 21 Jun 2016 00:33:17 -0700 (PDT) From: "marcel.taeumel" Marcel.Taeumel@hpi.de Subject: [squeak-dev] Re: [Vm-dev] System and user processes To: squeak-dev@lists.squeakfoundation.org Message-ID: 1466494397918-4902025.post@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 <
maxleske@
> 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:
- We introduce two subclasses of Process: SystemProcess and UserProcess
- We define #isSystemProcess and #isUserProcess
- We introduce #newSystemProcess and #newUserProcess
- 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
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.
It is implemented via composition, not inheritance.
Maybe it is name, ClientProcess, that made you assume it is a subclass of Process..? It is not. :)
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.
Processes already have names, which could facilitate a hierarchical naming if someone wanted, and list filtering in the Process browser would make "grouping" or "finding" a Process pretty much free..
If all you want to do is tag and group processes, I would consider putting them into named groups/containers rather than add more process-level attributes..
Chris Muller-3 wrote
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.
It is implemented via composition, not inheritance.
Maybe it is name, ClientProcess, that made you assume it is a subclass of Process..? It is not. :)
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.
Processes already have names, which could facilitate a hierarchical naming if someone wanted, and list filtering in the Process browser would make "grouping" or "finding" a Process pretty much free..
If all you want to do is tag and group processes, I would consider putting them into named groups/containers rather than add more process-level attributes..
Managing tags would be easier than managing groups. Tags are not so restictive compared to groups. Tags are like groups but more flexible. Take our message categories as an example. If those would be like tags, you wouldn't have to descide for a dominant structure:
accessing - geometry - private vs. geometry - accessing - private vs. private - geometry - accessing vs. ...
See?
Best, Marcel
-- View this message in context: http://forum.world.st/Re-System-and-user-processe-tp4902160p4902392.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org