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:
- We introduce two subclasses of Process: SystemProcess and UserProcess
- We define #isSystemProcess and #isUserProcess
- We introduce #newSystemProcess and #newUserProcess
- 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
squeak-dev@lists.squeakfoundation.org