[Pharo-project] Clock/Delay problems
I have seen this before, and it is probably related to other problems that we have been seeing lately: Basically the whole initialization of DateAndTime (class side) goes wrong. Could this have something to do with Delay problems ? Some time ago, there were some Delay changes, right ? I have not yet made an issue, as I think we should discuss a bit first. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Yes that is a very nasty bug, and I think it is not that easy to fix. If you really want to fix it we will have to fiddle with the whole startup mess. see comments in: https://code.google.com/p/pharo/issues/detail?id=7129 strangely enough it was introduced in 20460! image 20459 worked without problems. looking at the diffs doesn't reveal anything that could immediately cause the bug: 20459: https://github.com/pharo-project/pharo-core/commit/b83bda681530692a08efa4309... 20460: https://github.com/pharo-project/pharo-core/commit/16fe676a4ff25d720340ac8c4... 20461: https://github.com/pharo-project/pharo-core/commit/382d4c637b5f433edcb4d99d0... 20462: https://github.com/pharo-project/pharo-core/commit/2aece46a9ac922a81e931309c... the most probable change happened in 20462, but I am not sure if that is the cause. On 2013-02-11, at 14:54, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I have seen this before, and it is probably related to other problems that we have been seeing lately:
Basically the whole initialization of DateAndTime (class side) goes wrong.
Could this have something to do with Delay problems ?
Some time ago, there were some Delay changes, right ?
yeah, in the case the image hangs, there are always a couple (5 - 10) processes hanging in the image due to the DateAndTime offset initialization stuff. So my guess is that by making that lazily initialized we could get rid of the bug. maybe you can dig into that direction, I don't have much time at hand these days ;)
Sven can you add a bug entry because igor and camillo were discussing about the strange logic of DateAndTime? Stef On Feb 11, 2013, at 2:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I have seen this before, and it is probably related to other problems that we have been seeing lately:
<PharoScreenshot.png>
Basically the whole initialization of DateAndTime (class side) goes wrong.
Could this have something to do with Delay problems ?
Some time ago, there were some Delay changes, right ?
I have not yet made an issue, as I think we should discuss a bit first.
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 13 February 2013 18:01, stephane ducasse <stephane.ducasse@free.fr> wrote:
Sven
can you add a bug entry because igor and camillo were discussing about the strange logic of DateAndTime?
yeah.. i was looking at it recently (remember my post about DateAndTime nanosecond precision handling).. still did not found anything which causing the problems. there is too much stuff involved during startup... and since you cannot debug that code, you cannot see what happens :(
Stef
On Feb 11, 2013, at 2:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I have seen this before, and it is probably related to other problems that we have been seeing lately:
<PharoScreenshot.png>
Basically the whole initialization of DateAndTime (class side) goes wrong.
Could this have something to do with Delay problems ?
Some time ago, there were some Delay changes, right ?
I have not yet made an issue, as I think we should discuss a bit first.
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
-- Best regards, Igor Stasenko.
My personal take about this issue: - when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting). Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that). -- Best regards, Igor Stasenko.
Is this related to that large list of [delaySemaphore wait] in Delay>>wait that I do see in the Process Browser? This thing wasn't so large in the past. Phil 2013/2/13 Igor Stasenko <siguctua@gmail.com>:
My personal take about this issue:
- when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting).
Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that).
-- Best regards, Igor Stasenko.
On 13 Feb 2013, at 18:17, "phil@highoctane.be" <phil@highoctane.be> wrote:
Is this related to that large list of [delaySemaphore wait] in Delay>>wait that I do see in the Process Browser? This thing wasn't so large in the past.
Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image.
Phil
2013/2/13 Igor Stasenko <siguctua@gmail.com>:
My personal take about this issue:
- when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting).
Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that).
-- Best regards, Igor Stasenko.
Don't know if this is related but the 2.0 image seems to runs slower on my box (20543 now). Also a question: why is there a ZnServer in the StartUpList ? I saw discussions on the loading of .changes if there is none in the image folder. Phil 2013/2/13 Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Feb 2013, at 18:17, "phil@highoctane.be" <phil@highoctane.be> wrote:
Is this related to that large list of [delaySemaphore wait] in Delay>>wait that I do see in the Process Browser? This thing wasn't so large in the past.
Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image.
Phil
2013/2/13 Igor Stasenko <siguctua@gmail.com>:
My personal take about this issue:
- when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting).
Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that).
-- Best regards, Igor Stasenko.
Hi Phil, On 13 Feb 2013, at 18:39, "phil@highoctane.be" <phil@highoctane.be> wrote:
Don't know if this is related but the 2.0 image seems to runs slower on my box (20543 now).
That is hard to quantify, but any regressions should be investigated.
Also a question: why is there a ZnServer in the StartUpList ? I saw discussions on the loading of .changes if there is none in the image folder.
No, the automatic loading of .sources has become an option that is off by default. ZnServer is in the startup list, because it manages a list of registered server instances. If you create a ZnServer and it is registered, it will shutdown/restart on image shutdown/restart. This is something that is traditionally expected from servers running in a Smalltalk image. It can be handy during development, but I do not like it or use it for production systems. Sven
Phil
2013/2/13 Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Feb 2013, at 18:17, "phil@highoctane.be" <phil@highoctane.be> wrote:
Is this related to that large list of [delaySemaphore wait] in Delay>>wait that I do see in the Process Browser? This thing wasn't so large in the past.
Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image.
Phil
2013/2/13 Igor Stasenko <siguctua@gmail.com>:
My personal take about this issue:
- when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting).
Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that).
-- Best regards, Igor Stasenko.
On Feb 13, 2013, at 6:39 PM, phil@highoctane.be wrote:
Don't know if this is related but the 2.0 image seems to runs slower on my box (20543 now).
this is strange because people told me exactly the inverse yesterday (comparing to 1.4). So this is difficult to assess. Stef
Also a question: why is there a ZnServer in the StartUpList ? I saw discussions on the loading of .changes if there is none in the image folder.
Phil
2013/2/13 Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Feb 2013, at 18:17, "phil@highoctane.be" <phil@highoctane.be> wrote:
Is this related to that large list of [delaySemaphore wait] in Delay>>wait that I do see in the Process Browser? This thing wasn't so large in the past.
Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image.
Phil
2013/2/13 Igor Stasenko <siguctua@gmail.com>:
My personal take about this issue:
- when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting).
Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that).
-- Best regards, Igor Stasenko.
How can I test that? Really it feels sluggish when scrolling lists, autocomplete with Spotlight etc. Didn't have that with my 1.4. I am using a Mac with a Core2Duo CPU. RAM is of no concern (8GB). Phil 2013/2/13 stephane ducasse <stephane.ducasse@free.fr>:
On Feb 13, 2013, at 6:39 PM, phil@highoctane.be wrote:
Don't know if this is related but the 2.0 image seems to runs slower on my box (20543 now).
this is strange because people told me exactly the inverse yesterday (comparing to 1.4). So this is difficult to assess.
Stef
Also a question: why is there a ZnServer in the StartUpList ? I saw discussions on the loading of .changes if there is none in the image folder.
Phil
2013/2/13 Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Feb 2013, at 18:17, "phil@highoctane.be" <phil@highoctane.be> wrote:
Is this related to that large list of [delaySemaphore wait] in Delay>>wait that I do see in the Process Browser? This thing wasn't so large in the past.
Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image.
Phil
2013/2/13 Igor Stasenko <siguctua@gmail.com>:
My personal take about this issue:
- when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting).
Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that).
-- Best regards, Igor Stasenko.
On 2013-02-13, at 21:04, "phil@highoctane.be" <phil@highoctane.be> wrote:
How can I test that?
Really it feels sluggish when scrolling lists,
that is wrong, taking the latest 1.4 and the latest 2.0 there is a massive visual difference in scrolling speed on a huge list. I looked for senders of #name with 1583 items in 2.0 and 1408 in 1.4. Taking the scroll-thumb on the right, in 2.0 the list scrolls smoothly whereas in 1.4 it jumps. which version where you comparing?
autocomplete with Spotlight etc. Didn't have that with my 1.4.
What did you run here? Actually Spotlight could run slower ;) but I doubt that as well
I am using a Mac with a Core2Duo CPU. RAM is of no concern (8GB).
Phil
2013/2/13 stephane ducasse <stephane.ducasse@free.fr>:
On Feb 13, 2013, at 6:39 PM, phil@highoctane.be wrote:
Don't know if this is related but the 2.0 image seems to runs slower on my box (20543 now).
this is strange because people told me exactly the inverse yesterday (comparing to 1.4). So this is difficult to assess.
Stef
Also a question: why is there a ZnServer in the StartUpList ? I saw discussions on the loading of .changes if there is none in the image folder.
Phil
2013/2/13 Sven Van Caekenberghe <sven@stfx.eu>:
On 13 Feb 2013, at 18:17, "phil@highoctane.be" <phil@highoctane.be> wrote:
Is this related to that large list of [delaySemaphore wait] in Delay>>wait that I do see in the Process Browser? This thing wasn't so large in the past.
Let's hope so: it seems related, but we see it during startup (and subsequent crash) but also (sometimes) interactively in a working image.
Phil
2013/2/13 Igor Stasenko <siguctua@gmail.com>:
My personal take about this issue:
- when image starting up, all Delays should be reset by unblocking all waiting processes (regardless how much extra time there left to be waiting).
Because, to my opinion, a code which uses delays to cross session boundaries will fail badly anyways, so imo it is better to have delays unblocked the process prematurely, rather than blocking it for next 2^30 milliseconds (or any random big number around that).
-- Best regards, Igor Stasenko.
participants (5)
-
Camillo Bruni -
Igor Stasenko -
phil＠highoctane.be -
stephane ducasse -
Sven Van Caekenberghe