>> 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 <[email protected]> >> 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
