[Pharo-project] About process startups
I'm playing with the process initialization for the bootstrap, and some things come to my mind. There are some classes that startup processes on the class side initialize, like WeakArray -> Finalization process Delay -> Timer event loop What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess. Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on Guille
On Wed, May 16, 2012 at 3:27 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
I'm playing with the process initialization for the bootstrap, and some things come to my mind.
There are some classes that startup processes on the class side initialize, like
WeakArray -> Finalization process Delay -> Timer event loop
What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess.
Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like
MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on
Guille
I'm pretty sure that the there is no real binding between the class where the processes are created and the processes themself. The Pharo Kernel terminates all but this processes: InputEventFetcher default instVarNamed: #fetcherProcess. Processor activeProcess. WeakArray runningFinalizationProcess. Processor backgroundProcess. ...and it restarts this process: Delay startTimerEventLoop. I think that to have separate classes for the basic system processes is a good idea. -- Pavel
Instead of a block, your Process would perform an instance method like #run upon exec, while forking would just mean instantiating Process (and populating shared objetcs as ivars) ? Very much like Threads in other languages (Boost, Qt, etc...)... I find forking a block very light weight and powerfull, so your proposition effectively helps mainly for naming and classifying things (sic - I mean organizing). Note that almost all cases will be singleton. Maybe some isKindOf: will be required in the VM, did you check? Nicolas 2012/5/16 Guillermo Polito <guillermopolito@gmail.com>:
I'm playing with the process initialization for the bootstrap, and some things come to my mind.
There are some classes that startup processes on the class side initialize, like
WeakArray -> Finalization process Delay -> Timer event loop
What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess.
Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like
MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on
Guille
On Wed, May 16, 2012 at 4:30 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Instead of a block, your Process would perform an instance method like #run upon exec, while forking would just mean instantiating Process (and populating shared objetcs as ivars) ? Very much like Threads in other languages (Boost, Qt, etc...)...
I find forking a block very light weight and powerfull, so your proposition effectively helps mainly for naming and classifying things (sic - I mean organizing). Note that almost all cases will be singleton.
Maybe some isKindOf: will be required in the VM, did you check?
Maybe easier. Each reified process will just do the same [ self doSomeLoop ] forkNamed: 'asdasd'. that is now hidden in class side of whatever classes. So, nothing changes from the vm side, a lightweight process can still be created from a block, and the well known processes are something we can find easily :).
Nicolas
2012/5/16 Guillermo Polito <guillermopolito@gmail.com>:
I'm playing with the process initialization for the bootstrap, and some things come to my mind.
There are some classes that startup processes on the class side initialize, like
WeakArray -> Finalization process Delay -> Timer event loop
What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess.
Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like
MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on
Guille
I do not really like the class idea. May be having a convention + a pragma for the methods is good. Stef On May 16, 2012, at 3:27 PM, Guillermo Polito wrote:
I'm playing with the process initialization for the bootstrap, and some things come to my mind.
There are some classes that startup processes on the class side initialize, like
WeakArray -> Finalization process Delay -> Timer event loop
What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess.
Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like
MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on
Guille
On Wed, May 16, 2012 at 8:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I do not really like the class idea.
why not? Maybe it does not apply for every process, but for some of them. Morphic UI process could belong to MorphicUIManager, but, does the finalization process belong to weak array? why not to weak registry or weak ordered collection then? :S
May be having a convention + a pragma for the methods is good.
Stef
On May 16, 2012, at 3:27 PM, Guillermo Polito wrote:
I'm playing with the process initialization for the bootstrap, and some things come to my mind.
There are some classes that startup processes on the class side initialize, like
WeakArray -> Finalization process Delay -> Timer event loop
What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess.
Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like
MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on
Guille
On May 16, 2012, at 10:59 PM, Guillermo Polito wrote:
On Wed, May 16, 2012 at 8:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: I do not really like the class idea.
why not? Maybe it does not apply for every process, but for some of them.
Because I'm not sure that I like having one class per object.
Morphic UI process could belong to MorphicUIManager, but, does the finalization process belong to weak array? why not to weak registry or weak ordered collection then? :S
May be having a convention + a pragma for the methods is good.
Stef
On May 16, 2012, at 3:27 PM, Guillermo Polito wrote:
I'm playing with the process initialization for the bootstrap, and some things come to my mind.
There are some classes that startup processes on the class side initialize, like
WeakArray -> Finalization process Delay -> Timer event loop
What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess.
Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like
MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on
Guille
Do you want something like this? Process subclass: #PermanentSystemProcess PermanentSystemProcess subclass: #DelayProcess PermanentSystemProcess subclass: #WeakFinalizationProcess PermanentSystemProcess subclass: #UIProcess PermanentSystemProcess subclass: #IdleProcess ... On 17 May 2012 13:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On May 16, 2012, at 10:59 PM, Guillermo Polito wrote:
On Wed, May 16, 2012 at 8:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: I do not really like the class idea.
why not? Â Maybe it does not apply for every process, but for some of them.
Because I'm not sure that I like having one class per object.
Morphic UI process could belong to MorphicUIManager, but, does the finalization process belong to weak array? why not to weak registry or weak ordered collection then? :S
May be having a convention + a pragma for the methods is good.
Stef
On May 16, 2012, at 3:27 PM, Guillermo Polito wrote:
I'm playing with the process initialization for the bootstrap, and some things come to my mind.
There are some classes that startup processes on the class side initialize, like
WeakArray -> Finalization process Delay -> Timer event loop
What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Â Also, I can't stop thinking that the processes in the image are all spread and not clear. Â If I want to know where the processes are defined, it's kind of a mess.
Is having specialized objects for our processes undesired by some reason I can't see? Â I'd like to have objects like
MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on
Guille
-- Best regards, Igor Stasenko.
On Thu, May 17, 2012 at 3:22 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Do you want something like this?
Process subclass: #PermanentSystemProcess
PermanentSystemProcess subclass: #DelayProcess PermanentSystemProcess subclass: #WeakFinalizationProcess PermanentSystemProcess subclass: #UIProcess PermanentSystemProcess subclass: #IdleProcess ...
Hmm, really don't know what I want. Just know I do not like chaos some times :). I was asking if there is a reason for not doing something like you describe for example :P. Anyway. These permanent system processes should be documented somewhere, and the ability to find them, turn them on/off and install/uninstall them is kind of desirable for the bootstrap for example... And if I have to do it this way: (Process allInstances detect: [ :p | p name = 'blabla' ]) terminate (WeakArray classPool at: #FinalizationProcess) suspend seems me more like a hack than a real solution. Guille
On 17 May 2012 13:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On May 16, 2012, at 10:59 PM, Guillermo Polito wrote:
On Wed, May 16, 2012 at 8:59 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
I do not really like the class idea.
why not? Maybe it does not apply for every process, but for some of them.
Because I'm not sure that I like having one class per object.
Morphic UI process could belong to MorphicUIManager, but, does the finalization process belong to weak array? why not to weak registry or weak ordered collection then? :S
May be having a convention + a pragma for the methods is good.
Stef
On May 16, 2012, at 3:27 PM, Guillermo Polito wrote:
I'm playing with the process initialization for the bootstrap, and some things come to my mind.
There are some classes that startup processes on the class side initialize, like
WeakArray -> Finalization process Delay -> Timer event loop
What it is not clear to me is if those processes should be installed when the class is initialized, or when it is startupped for the first time. Also, I can't stop thinking that the processes in the image are all spread and not clear. If I want to know where the processes are defined, it's kind of a mess.
Is having specialized objects for our processes undesired by some reason I can't see? I'd like to have objects like
MorphicUIProcess FinalizationProcess TimeEventProcess ... and so on
Guille
-- Best regards, Igor Stasenko.
participants (5)
-
Guillermo Polito -
Igor Stasenko -
Nicolas Cellier -
Pavel Krivanek -
Stéphane Ducasse