Smalltalk › Instantiations

100% CPU usage after time being set on windows

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Louis LaBrunda

100% CPU usage after time being set on windows

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

--
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/-/fbIr3n_NIgoJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Marten Feldtmann-2

Re: 100% CPU usage after time being set on windows

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

--
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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

SebastianHC

Re: 100% CPU usage after time being set on windows

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

Am 12.07.2012 01:09, schrieb 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
>
> --
> 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 [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/va-smalltalk?hl=en.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.