[squeak-dev] Re: System and user processe

Max Leske maxleske at gmail.com
Tue Jun 21 13:27:24 UTC 2016


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

You essentially get my point. For the process browser a flag would be enough, yes, but that’s not really OO, is it… :)

Anyway, I see a couple of “direct” benefits:
- better implementation of user interrupt handling (user processes can always be interrupted)
- kill all user processes (system will keep running)
- different low space settings for system and user processes (yes, that would probably require a VM change, but still…)
- system processes could be prevented from starving (e.g. a user process must yield at least every n milliseconds)
...

> 
> Best,
> Marcel
> 
> 



More information about the Squeak-dev mailing list