[Vm-dev] Re: System and user processe
Max Leske
maxleske at gmail.com
Tue Jun 21 13:35:25 UTC 2016
> 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
More information about the Vm-dev
mailing list