>> 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 <tonyg at ccs.neu.edu> 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