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 |
Re: [squeak-dev] Re: System and user processe
|
|
>> 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.. |
Re: [squeak-dev] Re: System and user processe
|
|
Am 21.06.2016 um 17:37 schrieb Chris Muller <[hidden email]>: >>> 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.. > Norbert |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |