Win98/idle

Hi,

I am seeing an intermittent problem where a D5.1 fresh image is not entering
into idle on a slow Win98 machine. One effect of this is the user interface
does not get validated.

I cant reproduce it reliably; it shows up around 1 in 10 times that I open
an image. Opening a CHB and a workspace is enough to see whether the problem
is present or not. I have seen the problem in both a fresh 5.1 image and a
5.1 image patched with 1249 that Blair recently posted. The machine is an
old machine (p233) with a fresh install of Win98SE.

Doing a bit of digging in an image which has opened with the problem; I
found that InputState>>uiIdle never answers true because
InputState>>isInputAvailable always answers true. When I expect the image to
be entering into idle, the GetQueueStatus function answers 1048576 (I am
guessing this means that a WM_TIMER message is waiting, but
View>>wmTimer:wParam:lParam never gets sent), and InputState>>isInputReady:
is answering false.

My experimenting may have affected these results; I created a couple of
global collections and added the answers to them. Unfortunately I dont have
a MessageSpy like utility on that machine to dig any deeper into the
problem.

Anyone else seeing this?
Thanks,
Steve

--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html

Steve,

> I am seeing an intermittent problem where a D5.1 fresh image is not
entering
> into idle on a slow Win98 machine. One effect of this is the user
interface
> does not get validated.

First question.. just to try and narrow things down a bit.. did you see this
problem under D5.0?

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Hi Andy,

Andy Bower wrote:

> First question.. just to try and narrow things down a bit.. did you
> see this problem under D5.0?

No. I have 5.0.1 installed on that machine and I have not been able to
reproduce it. I cant rule it out, but I tried for about 20 minutes without
seeing the problem, then switched back to 5.1 and saw it within a minute.
The only applications that have been installed on that computer are D5.0.1,
D5.1 and a ToGo executable.

I have been able to reproduce it (D5.1 no patch) on a second machine; an old
Win95/IE5 laptop (p200).

I first noticed the problem testing a ToGo (that was deployed on a win2000
machine), commands were not being enabled/disabled. I have not seen it on my
win2000 development computer nor on any of the XP computers I have tested
on.

Steve
--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html

Steve

You wrote in message news:barkjl$2ouq6$[hidden email]...
>
> I am seeing an intermittent problem where a D5.1 fresh image is not
entering
> into idle on a slow Win98 machine. One effect of this is the user
interface
> does not get validated.

Am I understanding you correctly that the system does quiesce, but that the
UI revaliation idle processing is terminated early because the system thinks
there are messages to process when there aren't?

>
> I cant reproduce it reliably; it shows up around 1 in 10 times that I open
> an image. Opening a CHB and a workspace is enough to see whether the
problem
> is present or not. I have seen the problem in both a fresh 5.1 image and a
> 5.1 image patched with 1249 that Blair recently posted. The machine is an
> old machine (p233) with a fresh install of Win98SE.
>
> Doing a bit of digging in an image which has opened with the problem; I
> found that InputState>>uiIdle never answers true because
> InputState>>isInputAvailable always answers true. When I expect the image
to
> be entering into idle, the GetQueueStatus function answers 1048576 (I am
> guessing this means that a WM_TIMER message is waiting, but
> View>>wmTimer:wParam:lParam never gets sent), and
InputState>>isInputReady:
> is answering false.
> ...

Your interpretation is right, and a couple of things spring to mind:
1) A high-frequency timer really is operational, so you tend to see a timer
message waiting whenever you test. The only WM_TIMER used by the system
itself is that used to grab some CPU for background Smalltalk processes when
a Windows menu is show, or modal common dialog (such as the file open
dialog) is open. This ticks every 100mS, which ought to allow plenty of time
for idle time UI validation to complete, but on a slow machine such as a
P233 I suppose it might not if the queryCommand:s are complex, especially
without the 1249 patch. However, this timer is cancelled when the modal
operation completes, so it should not be ticking in normal circumstances. If
it is, then its possible there is some Win98 bug there. Certainly we have
experienced unreliability with the multimedia timers behind Dolphin's Delay
mechanism, although this usually manifests itself as a timer (and therefore
the Delay) failing to fire, which stalls the whole Delay mechanism (see
Delay class>>aboutToIdle for some further details). That said, we've never
experienced any problems with the standard Windows timers sent via the
message queue as WM_TIMER messages, these being entirely separate from the
high-resolution multimedia timers.

2) The #isInputAvailable method examines the high word of the return value
from GetQueueStatus(), the bits of which are supposed to reflect what types
of message are currently in the queue. The idle time UI validation calls
this in its loop to early out and process any messages that are pending.
Perhaps Win98 fails to reset these reliably. To test out this theory, you
might like to try http://www.object-arts.com/Lib/Update/Dolphin/5.1/1272.st
patch (along with #1249). This modifies the idle test to check only for the
arrival of new messages, which is sufficient.

3) Heisenberg effect (i.e. as you say, your experimenting may be affecting
the results).

Regards

Blair

Hi Blair,

Patch 1272 seems to have fixed the problem. Being intermittent, I cant be
100% sure, but I have tried over 50 times to reproduce it on D5.1+1249+1272
and did not see the problem. I would expect to see it occur at least 10 out
of the 50 if it was still a problem.

> Am I understanding you correctly that the system does quiesce, but
> that the UI revaliation idle processing is terminated early because
> the system thinks there are messages to process when there aren't?

Yes, a trace at the start of InputState>>aboutToIdle showed this method
being sent many times, while a trace at the start of the #ifTrue: block was
never being hit.

Thanks!

Steve
--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html

Steve

You wrote in message news:bb23no$4vv20$[hidden email]...
> ...
> Patch 1272 seems to have fixed the problem.

Great.

>...Being intermittent, I cant be
> 100% sure, but I have tried over 50 times to reproduce it on
D5.1+1249+1272
> and did not see the problem. I would expect to see it occur at least 10
out
> of the 50 if it was still a problem.

The patch is safe in theory (it being sufficient to early out of the idle
time UI revalidation on arrival of any new message). We'll run with it for a
while and see if any side effects show up.

>
> > Am I understanding you correctly that the system does quiesce, but
> > that the UI revaliation idle processing is terminated early because
> > the system thinks there are messages to process when there aren't?
>
> Yes, a trace at the start of InputState>>aboutToIdle showed this method
> being sent many times, while a trace at the start of the #ifTrue: block
was
> never being hit.

That does tend to suggest the root cause is a Win98 bug in the
implementation of GetQueueStatus() (i.e. failing to reset some queue status
bits), hence the non-appearance on 2k, etc.

Regards

Blair