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