Smalltalk › Pharo › Pharo Smalltalk Developers

System and user processes

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Max Leske

System and user processes

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

Chris Muller-3

Re: [Vm-dev] System and user processes

Hi Max, I had a similar idea, and made a ClientProcess class. Its
primary purpose is to provide a nice wrapping API for *users* to
manage their "background running tasks" (i.e., #start, #stop, #pause,
#resume, #progress, #priority adjustment), as well as a nice API for
*developers* to report its progress via a simple signaling mechanism,
which also gives the user all the performance stats for "free" too
like #unitsCompleted, #runningTime, #ratePerSecond, #remainingTime,
etc.

On Sun, Jun 19, 2016 at 4:03 AM, Max Leske <[hidden email]> 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

Max Leske

Re: [Vm-dev] System and user processes

> On 20 Jun 2016, at 19:48, Chris Muller <[hidden email]> wrote:
>
> Hi Max, I had a similar idea, and made a ClientProcess class. Its
> primary purpose is to provide a nice wrapping API for *users* to
> manage their "background running tasks" (i.e., #start, #stop, #pause,
> #resume, #progress, #priority adjustment), as well as a nice API for
> *developers* to report its progress via a simple signaling mechanism,
> which also gives the user all the performance stats for "free" too
> like #unitsCompleted, #runningTime, #ratePerSecond, #remainingTime,
> etc.

Very nice! So I don’t seem to be the only one to think there may be room for improvement :)
Your idea focuses on a different aspect of course but both ideas would go well together I think. Is your code public somewhere? Just in case this gains some traction.

Cheers,
Max

>
> On Sun, Jun 19, 2016 at 4:03 AM, Max Leske <[hidden email]> 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
>