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 |
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/b83bda681530692a08efa4309aff97fa9a4826a7 20460: https://github.com/pharo-project/pharo-core/commit/16fe676a4ff25d720340ac8c49c40157cae70e96 20461: https://github.com/pharo-project/pharo-core/commit/382d4c637b5f433edcb4d99d075d2bb5a81824c5 20462: https://github.com/pharo-project/pharo-core/commit/2aece46a9ac922a81e931309c4d6faf7e24d034d 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 <[hidden email]> 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 ;) |
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]> wrote:
|
On 13 February 2013 18:01, stephane ducasse <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>: > 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, "[hidden email]" <[hidden email]> 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 <[hidden email]>: >> 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 <[hidden email]>: > > On 13 Feb 2013, at 18:17, "[hidden email]" <[hidden email]> 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 <[hidden email]>: >>> 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, "[hidden email]" <[hidden email]> 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 <[hidden email]>: >> >> On 13 Feb 2013, at 18:17, "[hidden email]" <[hidden email]> 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 <[hidden email]>: >>>> 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. >>>> >>> >> >> > |
In reply to this post by philippeback
On Feb 13, 2013, at 6:39 PM, [hidden email] 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 <[hidden email]>: >> >> On 13 Feb 2013, at 18:17, "[hidden email]" <[hidden email]> 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 <[hidden email]>: >>>> 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 <[hidden email]>: > > On Feb 13, 2013, at 6:39 PM, [hidden email] 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 <[hidden email]>: >>> >>> On 13 Feb 2013, at 18:17, "[hidden email]" <[hidden email]> 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 <[hidden email]>: >>>>> 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, "[hidden email]" <[hidden email]> 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 <[hidden email]>: >> >> On Feb 13, 2013, at 6:39 PM, [hidden email] 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 <[hidden email]>: >>>> >>>> On 13 Feb 2013, at 18:17, "[hidden email]" <[hidden email]> 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 <[hidden email]>: >>>>>> 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. >>>>>> >>>>> >>>> >>>> >>> >> >> > |
Free forum by Nabble | Edit this page |