Re: System and user processe
Locked
 
|
> 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 > > 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… You essentially get my point. For the process browser a flag would be enough, yes, but that’s not really OO, is it… :) Anyway, I see a couple of “direct” benefits: - better implementation of user interrupt handling (user processes can always be interrupted) - kill all user processes (system will keep running) - different low space settings for system and user processes (yes, that would probably require a VM change, but still…) - system processes could be prevented from starving (e.g. a user process must yield at least every n milliseconds) ... > > Best, > Marcel > > |
|
|
> 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. I agree. I just wanted to get the idea out there without proposing a complete POSIX process model. And I found it interesting that we actually could use subclasses without needing special support from the VM. > > 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 I think that grouping makes a lot of sense. However, the current model has also served us well, maybe exactly because it is simple. Adding a lot of complexity will not necessarily make things better (especially for newcomers). Maybe there’s a middle ground where high level processes maintain a very simple API (like Chris proposed) and where you don’t have to know about process groups (those processes might just go into a default group, essentially what you describe with “current process group"). Really not sure… 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 |
|
|
In reply to this post by Max Leske
>> 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 Yes. That’s why in my proposal the default is to create a user process. Cheers, Max |
|
|
In reply to this post by Max Leske
>> Message: 17
>> Date: Tue, 21 Jun 2016 00:33:17 -0700 (PDT) >> From: "marcel.taeumel" <[hidden email]> >> Subject: [squeak-dev] Re: [Vm-dev] System and user processes >> To: [hidden email] >> Message-ID: <[hidden email]> >> 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: >> >> 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 |
|
|
>> 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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |