Clock/Delay problems

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Clock/Delay problems

Sven Van Caekenberghe-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

Camillo Bruni-3
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 ;)
Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

stephane ducasse
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:

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


Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

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.

Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

philippeback
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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

Sven Van Caekenberghe-2

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.
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

philippeback
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.
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

Sven Van Caekenberghe-2
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.
>>>>
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

stephane ducasse
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.
>>>>
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

philippeback
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.
>>>>>
>>>>
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Clock/Delay problems

Camillo Bruni-3

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.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>