100% CPU usage after time being set on windows

[Louis LaBrunda]

Hi All,

Yesterday I experienced a problem where some of my windows NT services jumped to using 100% CPU after setting the time in windows back by about 30 seconds.  This happened with programs build with VA Smalltalk V8.0.3.  It has also happened with builds from V5.5.2.  It sometimes happens at the summer/winter time change and maybe the winter/summer time change but I can't remember for sure.

It doesn't always happen to all programs running when the time is set.  For example, yesterday I think there were more than ten programs running but I think only four went to 100% CPU.  The programs kept running and doing useful work all-be-it maybe a little slow.

The problem can always be with the developers code (that's me) but I don't see anything I'm doing that would care about the time changing forward or backward.  The servers have different numbers of forks all of which issue a delay when they don't have anything to do.  I can't see why they wouldn't continue to function the same after a time change.

Looking at the Delay class code for #checkDelayedTasks, there are comments about Time millisecondClockValue possibly going backwards with a system time change.  For example going backwards by an hour with summer/winter time change.  My tests show that this doesn't happen.  The millisecondClockValue always seems to move forward.  That said, I don't think there is any problem with the code and even if there were less code that didn't consider the value going backwards (getting smaller) the code all looks good.

That leaves us with the VM.  Is there something in the VM what would cause it to use 100% of the CPU after a time change?  Could it not be giving the CPU back to the OS?  Remember the programs seem to keep working.  Could they get to a point where they have nothing to do and not relinquish the CPU?  Could the idle process (loop/fork) have died?  If so, is it my job to create a new one?

Thanks in advance for any help, thoughts, ideas, anything.

Lou

[Marten Feldtmann]

Normally I would guess, that this behaviour happens due to one problem:

* the GUI thread (main Smalltalk-thread) is busy doing stuff

This "busy" may be due to the fact, that the program is doing really hard work or something is executed, that suspend the GUI thread.

The most well known reason is a Delay>>wait in the GUI thread. This suspends the GUI thread and forces the Smalltalk system to do an active event polling - leading to 100% CPU-kernel usage.

Another reason is the usage of a Delay>>wait during a callback into the image or when process switching has been disabled, then an active "waiting" is initiated.

Not a direct answer to your question ... I know

[Sebastian Heidbrink]

Hi!

I once had a case where the 2007 omplementation of CwAppContext #idle method
prdouced 100% cpu load.

Maybe you may check whether you problem occurs with the 1996
implementation,too, or not.

Sebastian

> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/va-smalltalk/-/gKwCOLT3EQQJ.
> To post to this group, send email to va-sma...@googlegroups.com.
> To unsubscribe from this group, send email to
> va-smalltalk...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/va-smalltalk?hl=en.