There are still lots of Delay>>wait Processes
Hi, It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processe... is closed, but the problem remains. Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes. ⦠This is not good ;-) The least we should do is add some script in the release/build process to kill them. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote:
Hi,
It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processe... is closed, but the problem remains.
Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes.
â¦
<Screen Shot 2013-06-18 at 09.30.30.png>
This is not good ;-)
The least we should do is add some script in the release/build process to kill them.
I added the following to my startup preferences: Process allInstances do: [ :process | process suspendedContext ifNotNil: [ :context | context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ]
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel@gmail.com> wrote:
On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote:
Hi,
It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processe... is closed, but the problem remains.
Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes.
â¦
<Screen Shot 2013-06-18 at 09.30.30.png>
This is not good ;-)
The least we should do is add some script in the release/build process to kill them.
I added the following to my startup preferences:
Process allInstances do: [ :process | process suspendedContext ifNotNil: [ :context | context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ]
OK, thanks. But are we sure that no legitimate ones are killed ? I am not sure, but I believe Igor's script had more testsâ¦.
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
the original issue you posted was closed because it is a duplicate of this one https://pharo.fogbugz.com/default.asp?7526 where you will fine a proper script to kill hanging processes... On 2013-06-18, at 10:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel@gmail.com> wrote:
On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote:
Hi,
It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processe... is closed, but the problem remains.
Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes.
â¦
<Screen Shot 2013-06-18 at 09.30.30.png>
This is not good ;-)
The least we should do is add some script in the release/build process to kill them.
I added the following to my startup preferences:
Process allInstances do: [ :process | process suspendedContext ifNotNil: [ :context | context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ]
OK, thanks. But are we sure that no legitimate ones are killed ? I am not sure, but I believe Igor's script had more testsâ¦.
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On 18 Jun 2013, at 10:38, Camillo Bruni <camillobruni@gmail.com> wrote:
the original issue you posted was closed because it is a duplicate of this one https://pharo.fogbugz.com/default.asp?7526
I saw that, but the title is too restrictive I think.
where you will fine a proper script to kill hanging processesâ¦
OK, but it is not good to keep on producing images with all this shit in them. Maybe we need some QA type unit test that checks for unexpected processes.
On 2013-06-18, at 10:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel@gmail.com> wrote:
On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote:
Hi,
It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processe... is closed, but the problem remains.
Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes.
â¦
<Screen Shot 2013-06-18 at 09.30.30.png>
This is not good ;-)
The least we should do is add some script in the release/build process to kill them.
I added the following to my startup preferences:
Process allInstances do: [ :process | process suspendedContext ifNotNil: [ :context | context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ]
OK, thanks. But are we sure that no legitimate ones are killed ? I am not sure, but I believe Igor's script had more testsâ¦.
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Once igor finishes the TxModel and Athens it was planned to address the Delay problem. Stef
On 18 June 2013 11:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Once igor finishes the TxModel and Athens it was planned to address the Delay problem.
I don't think i am the only one who capable to fix it. :) Something broken in restoring Delay(s) after image restart (they hanging for too far in the future). That's my impression.
From other side, i do not see why Cookie should use [ Delay forEons wait] fork. Instead, i would just replace implementation with code which checks the time before giving answer of cookie value. So, if you won't use cookie value in heavy numerical-crunchy calculations, this is completely fine.
Stef
-- Best regards, Igor Stasenko.
On Jun 18, 2013, at 11:17 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 18 June 2013 11:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Once igor finishes the TxModel and Athens it was planned to address the Delay problem.
I don't think i am the only one who capable to fix it. :)
I would love to be able to do it :)
Something broken in restoring Delay(s) after image restart (they hanging for too far in the future). That's my impression. From other side, i do not see why Cookie should use [ Delay forEons wait] fork. Instead, i would just replace implementation with code which checks the time before giving answer of cookie value. So, if you won't use cookie value in heavy numerical-crunchy calculations, this is completely fine.
Stef
-- Best regards, Igor Stasenko.
You may not be the only one, but you probably are the only whose job is to address Pharo issues :) Ben On Jun 18, 2013, at 11:17 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 18 June 2013 11:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Once igor finishes the TxModel and Athens it was planned to address the Delay problem.
I don't think i am the only one who capable to fix it. :)
Something broken in restoring Delay(s) after image restart (they hanging for too far in the future). That's my impression. From other side, i do not see why Cookie should use [ Delay forEons wait] fork. Instead, i would just replace implementation with code which checks the time before giving answer of cookie value. So, if you won't use cookie value in heavy numerical-crunchy calculations, this is completely fine.
Stef
-- Best regards, Igor Stasenko.
On 18 June 2013 14:43, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
You may not be the only one, but you probably are the only whose job is to address Pharo issues :)
Toucher! :) Yes, i should look again at Delays.
Ben
On Jun 18, 2013, at 11:17 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 18 June 2013 11:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Once igor finishes the TxModel and Athens it was planned to address the Delay problem.
I don't think i am the only one who capable to fix it. :)
Something broken in restoring Delay(s) after image restart (they hanging for too far in the future). That's my impression. From other side, i do not see why Cookie should use [ Delay forEons wait] fork. Instead, i would just replace implementation with code which checks the time before giving answer of cookie value. So, if you won't use cookie value in heavy numerical-crunchy calculations, this is completely fine.
Stef
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 18 Jun 2013, at 14:43, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
You may not be the only one, but you probably are the only whose job is to address Pharo issues :)
And we all get this warm cozy feeling when Igor fixes important low level stuff ;-)
Ben
On Jun 18, 2013, at 11:17 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 18 June 2013 11:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Once igor finishes the TxModel and Athens it was planned to address the Delay problem.
I don't think i am the only one who capable to fix it. :)
Something broken in restoring Delay(s) after image restart (they hanging for too far in the future). That's my impression. From other side, i do not see why Cookie should use [ Delay forEons wait] fork. Instead, i would just replace implementation with code which checks the time before giving answer of cookie value. So, if you won't use cookie value in heavy numerical-crunchy calculations, this is completely fine.
Stef
-- Best regards, Igor Stasenko.
On 18 June 2013 16:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Jun 2013, at 14:43, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
You may not be the only one, but you probably are the only whose job is to address Pharo issues :)
And we all get this warm cozy feeling when Igor fixes important low level stuff ;-)
hear hear... same about you, when you making new update for zinc stuff :)
Ben
On Jun 18, 2013, at 11:17 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 18 June 2013 11:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Once igor finishes the TxModel and Athens it was planned to address the Delay problem.
I don't think i am the only one who capable to fix it. :)
Something broken in restoring Delay(s) after image restart (they hanging for too far in the future). That's my impression. From other side, i do not see why Cookie should use [ Delay forEons wait] fork. Instead, i would just replace implementation with code which checks the time before giving answer of cookie value. So, if you won't use cookie value in heavy numerical-crunchy calculations, this is completely fine.
Stef
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 18 juin 2013, at 10:05, Sven Van Caekenberghe wrote:
On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel@gmail.com> wrote:
On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote:
Hi,
It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-processe... is closed, but the problem remains.
Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes.
â¦
<Screen Shot 2013-06-18 at 09.30.30.png>
This is not good ;-)
The least we should do is add some script in the release/build process to kill them.
I added the following to my startup preferences:
Process allInstances do: [ :process | process suspendedContext ifNotNil: [ :context | context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ]
OK, thanks. But are we sure that no legitimate ones are killed ? I am not sure, but I believe Igor's script had more testsâ¦.
Ok I did't saw Igor's one. Indeed mine doesn't check context sender sender sender method selector == #contents:
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
participants (6)
-
Benjamin -
Camille Teruel -
Camillo Bruni -
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe