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...

Best,
Marcel



--
View this message in context: http://forum.world.st/System-and-user-processes-tp4901765p4901914.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.