Chris Muller-3 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.
> 
> On Sun, Jun 19, 2016 at 4:03 AM, Max Leske <

> maxleske@

> > 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 Chris,

Hmm... I would implement such an API rather via composition than
inheritance. Such a task does not necessarily have to run in the same image
but could also be accomplished on another machine. OSProcess has RemoteTask
for this. Inheritance would make things complicated once one would decide to
not carry out the computation as a Squeak process.

I do like Tony's idea of process groups. We could think this one step
further an add multiple tags (symbols?) to processes to support
fine-granular or cross-cutting classifications. Tools like the process
browser could show these tags, group by them, etc. There could be tags to
identify processes that would stop working once you close the Squeak image
(e.g. "not resumable")... Hmmm... Application developers could use tags to
provide hints for other developers and users.

Best,
Marcel



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