System and user processes
Locked
 
|
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 Max, I like the idea. Let's see... System processes in Squeak could be: - the timer interrupt watcher - the event tickler - the low space watcher - the user interrupt watcher - the idle process I am not so sure about: - the WeakArray finalization process (still needed for Ephemerons?) Then we have the UI framework(s). The frameworks' processes could be user processes or system processes, too? Hmm... for Morphic, there is only one. Stepping is implemented with the same UI process. Applications that spawn other (user) processes work around Morphic anyway. Tweak uses (or used) many processes to execute scripts. So, the Tweak UI has a set of related processes, not just a single UI process. MVC has only one process running but creates/terminates processes when switching controllers. If you play a MIDI or a Sound, should that process also be a system process, right? Hmm... Interactive debugging is tricky only with respect to the current UI framework because you want to be able to also debug that frameworks code and its applications. While writing the debugger in that framework, too. So, it is above the level of processes but at the level of the UI framework (resp. projects). At least in Squeak. Hmm... for a filter in the process browser, a simple flag would be enough. No need to add subclasses. So, whout be the benefits of distinguishing between UserProcess and SystemProcess at process creation time? How to decide? Might it be related to additional warnings? Calling "Smalltalk snapshot: true andQuit: true" from a process in an endless loop might be detected if you do that from within a UserProcess. :-D Maybe introduce restrictions/warnings at the level of message dispatch for UserProcesses? Hmm... Best, Marcel |
Re: [Vm-dev] System and user processes
|
|
In reply to this post by Max Leske
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 <[hidden email]> 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 |
Re: System and user processes
|
|
In reply to this post by Max Leske
Hi Max,
Perhaps a notion of process grouping might make sense? Following the zero-one-infinity principle, having exactly two kinds of process seems a bit odd. Having process grouping would lead to a tree of processes. For example, the outermost level could be "system" processes, of which one was a group containing all "user" processes. Or, the outermost level could have two children, one group of "system" procs, one of "user" procs; or, ... The "current process group" would be a kind of dynamic parameter, and newly-forked processes would by default become siblings of the forker in the current group. Regards, Tony On 06/19/2016 05:03 AM, Max Leske 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 > |
|
|
> On 06/19/2016 05:03 AM, Max Leske 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 >> > On Tue, Jun 21, 2016 at 3:32 AM, Tony Garnock-Jones <[hidden email]> wrote: > Hi Max, > > Perhaps a notion of process grouping might make sense? Following the > zero-one-infinity principle, having exactly two kinds of process seems a > bit odd. > > Having process grouping would lead to a tree of processes. > > For example, the outermost level could be "system" processes, of which > one was a group containing all "user" processes. > > Or, the outermost level could have two children, one group of "system" > procs, one of "user" procs; or, ... > > The "current process group" would be a kind of dynamic parameter, and > newly-forked processes would by default become siblings of the forker in > the current group. > > Regards, > Tony This sounds like a good idea. It would make it easier for a user of multiple applications in one image to properly kill one. For this reason, perhaps there should be some impediment on apps adding processes adding the System Process group(??) cheers -ben |
|
|
In reply to this post by Chris Muller-3
> On 20 Jun 2016, at 19:48, Chris Muller <[hidden email]> 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. Very nice! So I don’t seem to be the only one to think there may be room for improvement :) Your idea focuses on a different aspect of course but both ideas would go well together I think. Is your code public somewhere? Just in case this gains some traction. Cheers, Max > > On Sun, Jun 19, 2016 at 4:03 AM, Max Leske <[hidden email]> 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 > |
Re: [Vm-dev] System and user processes
|
|
In reply to this post by Chris Muller-3
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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |