why so many processes are running at startup time?
There are 30 over processes are running at startup, Pharo-20607.image. [image: åãè¾¼ã¿ç»å 1] regards. -- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
Hello, These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days. As a workaround, you can just kill these processes in your image for now ... Thanks for reporting the issue, 2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com>
There are 30 over processes are running at startup, Pharo-20607.image.
[image: åãè¾¼ã¿ç»å 1]
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
Hi, I think we should for now just kill them when building the image, I will check. On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com> There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
thx. I run a cleaning processes script such as: (Process allInstances reject: [ :p | {(InputEventFetcher default fetcherProcess). (Processor activeProcess). (WeakArray runningFinalizationProcess). (Processor backgroundProcess). (SmalltalkImage current lowSpaceWatcherProcess). (UIManager default uiProcess). (Delay schedulingProcess)} includes: p ]) do: [ :p | p suspend; terminate ] and get 6 processes remain: (80) 745275392: Delay class>>handleTimerEvent (60) Input events fetching process: InputEventFetcher>>waitForInput (60) 1061945344: SmalltalkImage>>lowSpaceWatcher (50) 946339840: WeakArray class>>finalizationProcess (40s) Morphic UI process: nil (10) 845938688: ProcessorScheduler class>>idleProcess is this OK? regards. 2013/6/20 Marcus Denker <marcus.denker@inria.fr>
Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com>
There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
IMO looks good On 2013-06-20, at 12:18, NISHIHARA Satoshi <goonsh@gmail.com> wrote:
thx.
I run a cleaning processes script such as: (Process allInstances reject: [ :p | {(InputEventFetcher default fetcherProcess). (Processor activeProcess). (WeakArray runningFinalizationProcess). (Processor backgroundProcess). (SmalltalkImage current lowSpaceWatcherProcess). (UIManager default uiProcess). (Delay schedulingProcess)} includes: p ]) do: [ :p | p suspend; terminate ]
and get 6 processes remain: (80) 745275392: Delay class>>handleTimerEvent (60) Input events fetching process: InputEventFetcher>>waitForInput (60) 1061945344: SmalltalkImage>>lowSpaceWatcher (50) 946339840: WeakArray class>>finalizationProcess (40s) Morphic UI process: nil (10) 845938688: ProcessorScheduler class>>idleProcess
is this OK?
regards.
2013/6/20 Marcus Denker <marcus.denker@inria.fr>
Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com>
There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
Hi Satoshi, On 20 Jun 2013, at 12:18, NISHIHARA Satoshi <goonsh@gmail.com> wrote:
thx.
I run a cleaning processes script such as: (Process allInstances reject: [ :p | {(InputEventFetcher default fetcherProcess). (Processor activeProcess). (WeakArray runningFinalizationProcess). (Processor backgroundProcess). (SmalltalkImage current lowSpaceWatcherProcess). (UIManager default uiProcess). (Delay schedulingProcess)} includes: p ]) do: [ :p | p suspend; terminate ]
This code looks like a nice start for writing a unit test that could verify that there are no bogus processes in delivered images. We already have a number of tests that do global quality checks (like Undeclared, bogus instances, ..), we need this as well. Any opinions, comments ? Sven
and get 6 processes remain: (80) 745275392: Delay class>>handleTimerEvent (60) Input events fetching process: InputEventFetcher>>waitForInput (60) 1061945344: SmalltalkImage>>lowSpaceWatcher (50) 946339840: WeakArray class>>finalizationProcess (40s) Morphic UI process: nil (10) 845938688: ProcessorScheduler class>>idleProcess
is this OK?
regards.
2013/6/20 Marcus Denker <marcus.denker@inria.fr> Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com> There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
Caekenberghe san 11 lines of code in previous e-mail, extracted from SmalltalkImage>> privCleanProcesses (20607 image), and modified. Browser fullOnClass: SmalltalkImage selector: #privCleanProcesses. or Nautilus fullOnClass: SmalltalkImage selector: #privCleanProcesses. please use freely. regards. 2013/6/21 Sven Van Caekenberghe <sven@stfx.eu>
Hi Satoshi,
On 20 Jun 2013, at 12:18, NISHIHARA Satoshi <goonsh@gmail.com> wrote:
thx.
I run a cleaning processes script such as: (Process allInstances reject: [ :p | {(InputEventFetcher default fetcherProcess). (Processor activeProcess). (WeakArray runningFinalizationProcess). (Processor backgroundProcess). (SmalltalkImage current lowSpaceWatcherProcess). (UIManager default uiProcess). (Delay schedulingProcess)} includes: p ]) do: [ :p | p suspend; terminate ]
This code looks like a nice start for writing a unit test that could verify that there are no bogus processes in delivered images.
We already have a number of tests that do global quality checks (like Undeclared, bogus instances, ..), we need this as well.
Any opinions, comments ?
Sven
and get 6 processes remain: (80) 745275392: Delay class>>handleTimerEvent (60) Input events fetching process: InputEventFetcher>>waitForInput (60) 1061945344: SmalltalkImage>>lowSpaceWatcher (50) 946339840: WeakArray class>>finalizationProcess (40s) Morphic UI process: nil (10) 845938688: ProcessorScheduler class>>idleProcess
is this OK?
regards.
2013/6/20 Marcus Denker <marcus.denker@inria.fr> Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com> There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
On 20 June 2013 19:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Satoshi,
On 20 Jun 2013, at 12:18, NISHIHARA Satoshi <goonsh@gmail.com> wrote:
thx.
I run a cleaning processes script such as: (Process allInstances reject: [ :p | {(InputEventFetcher default fetcherProcess). (Processor activeProcess). (WeakArray runningFinalizationProcess). (Processor backgroundProcess). (SmalltalkImage current lowSpaceWatcherProcess). (UIManager default uiProcess). (Delay schedulingProcess)} includes: p ]) do: [ :p | p suspend; terminate ]
This code looks like a nice start for writing a unit test that could verify that there are no bogus processes in delivered images.
We already have a number of tests that do global quality checks (like Undeclared, bogus instances, ..), we need this as well.
Any opinions, comments ?
Yes, the only thing i hate in this code is references to many different classes. These processes actually represent various basic services of the system. so i would prefer that these services register themselves somewhere, like that we could have a clean code, something like: services collect: [:each | each process ] like that, you don't need to modify this method evry time you changing the list/implementation etc.
Sven
and get 6 processes remain: (80) 745275392: Delay class>>handleTimerEvent (60) Input events fetching process: InputEventFetcher>>waitForInput (60) 1061945344: SmalltalkImage>>lowSpaceWatcher (50) 946339840: WeakArray class>>finalizationProcess (40s) Morphic UI process: nil (10) 845938688: ProcessorScheduler class>>idleProcess
is this OK?
regards.
2013/6/20 Marcus Denker <marcus.denker@inria.fr> Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com> There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Best regards, Igor Stasenko.
Igor, On 21 Jun 2013, at 13:27, Igor Stasenko <siguctua@gmail.com> wrote:
Yes, the only thing i hate in this code is references to many different classes. These processes actually represent various basic services of the system. so i would prefer that these services register themselves somewhere, like that we could have a clean code, something like:
services collect: [:each | each process ]
like that, you don't need to modify this method evry time you changing the list/implementation etc.
I implemented this on ReleaseTest, with a fixed list, for now. I understand your remark: some form of dependency injection is cleaner and more extensible/scaleable indeed. However, in this particular case, I am not 100% convinced: your dynamic list based on registration can only be as good as the registrars, if they make a mistake (failing to unregister), the list will become bad. Sven
Sven
and get 6 processes remain: (80) 745275392: Delay class>>handleTimerEvent (60) Input events fetching process: InputEventFetcher>>waitForInput (60) 1061945344: SmalltalkImage>>lowSpaceWatcher (50) 946339840: WeakArray class>>finalizationProcess (40s) Morphic UI process: nil (10) 845938688: ProcessorScheduler class>>idleProcess
is this OK?
regards.
2013/6/20 Marcus Denker <marcus.denker@inria.fr> Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com> There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
On 24 June 2013 11:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Igor,
On 21 Jun 2013, at 13:27, Igor Stasenko <siguctua@gmail.com> wrote:
Yes, the only thing i hate in this code is references to many different classes. These processes actually represent various basic services of the system. so i would prefer that these services register themselves somewhere, like that we could have a clean code, something like:
services collect: [:each | each process ]
like that, you don't need to modify this method evry time you changing the list/implementation etc.
I implemented this on ReleaseTest, with a fixed list, for now.
I understand your remark: some form of dependency injection is cleaner and more extensible/scaleable indeed.
However, in this particular case, I am not 100% convinced: your dynamic list based on registration can only be as good as the registrars, if they make a mistake (failing to unregister), the list will become bad.
there can be a compromise :) a) make method, which contains list of exact class names (services) b) make sure that these classes understand same protocol, so that in other method you do: self services collect: [:each | each processThatIsValidWhatever ]
Sven
Sven
and get 6 processes remain: (80) 745275392: Delay class>>handleTimerEvent (60) Input events fetching process: InputEventFetcher>>waitForInput (60) 1061945344: SmalltalkImage>>lowSpaceWatcher (50) 946339840: WeakArray class>>finalizationProcess (40s) Morphic UI process: nil (10) 845938688: ProcessorScheduler class>>idleProcess
is this OK?
regards.
2013/6/20 Marcus Denker <marcus.denker@inria.fr> Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com> There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Best regards, Igor Stasenko.
I propose to enable again that on image startup the timer scheduling process is restarted. https://pharo.fogbugz.com/default.asp?10994 https://pharo.fogbugz.com/default.asp?10545 I am not fully sure of the implications, but it used to be there before and I have less troubles when it is enabled ;) On 2013-06-20, at 10:02, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com> There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Camillo, Let's hope you found the problem, make sure to double check with the team over there. I added https://pharo.fogbugz.com/f/cases/10998/Add-ReleaseTest-testUnknownProcesses but this might be hard to make work in practice. Sven On 23 Jun 2013, at 14:47, Camillo Bruni <camillobruni@gmail.com> wrote:
I propose to enable again that on image startup the timer scheduling process is restarted.
https://pharo.fogbugz.com/default.asp?10994 https://pharo.fogbugz.com/default.asp?10545
I am not fully sure of the implications, but it used to be there before and I have less troubles when it is enabled ;)
On 2013-06-20, at 10:02, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
I think we should for now just kill them when building the image, I will check.
On Jun 20, 2013, at 9:56 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. We will fix that within a few days.
As a workaround, you can just kill these processes in your image for now ...
Thanks for reporting the issue,
2013/6/20 NISHIHARA Satoshi <goonsh@gmail.com> There are 30 over processes are running at startup, Pharo-20607.image.
<NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png>
regards.
-- -- "NISHIHARA Satoshi" [:goonsh :nsh | ^ nishis perform: goonsh with: nsh]
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
On 2013-06-23, at 21:02, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Camillo,
Let's hope you found the problem, make sure to double check with the team over there.
I added https://pharo.fogbugz.com/f/cases/10998/Add-ReleaseTest-testUnknownProcesses but this might be hard to make work in practice.
I think this is perfectly fine. A freshly shipped image shouldn't have more than a handful of known processes running...
participants (6)
-
Camillo Bruni -
Clément Bera -
Igor Stasenko -
Marcus Denker -
NISHIHARA Satoshi -
Sven Van Caekenberghe