Are timer events queued?

Tags: #<Tag:0x00007f225530cba8>

Hi,
I have a hand written process procedure that uses the window timer to allow access to the OS. Basically the process runs through a given number of records and exits. Then on the next EVENT:TIMER, I call YIELD and then continue processing the records from where I was the previous time. This repeats until all the records are processed.

I have the TIMER set to 1.

The process works fine, except for one thing. The window doesn’t seem to be yielding to the OS. I can’t move the window with the mouse, and I can’t cancel the process by pressing the button I have for this purpose.

I don’t know what could be the problem, but the only explanation I have is that the TIMER events are getting queued, and thus interfere with other events such as moving the window or pressing a button on the window.

Are timer events queued? Or can you guys think of another cause?

Thanks,
Edgard

Not sure if they’re getting queued, but I usually shut off the timer while I’m processing through “a given number of records”.

Perhaps it would help you to rule that out.

e.g.

 OF EVENT:Timer
   0{PROP:Timer} = 0
   DO ProcessRecords
   0{PROP:Timer} = MyTimerSetting

Hi Jeff,
Excellent idea! I will try that. Thanks.

BTW, I had a question I wanted to ask you about your sqlite memory table example, but I will post as a new question so it can be better referenced by others.

There should be no need to YIELD(). That may be causing you problems. Post an except of your code.

Each Event:Timer you process a reasonable number of records, say 20 to 50, it depends on how complex and large of files. Will it be on a LAN or WAN.

OF EVENT:Timer
   LOOP 20 TIMES
      NEXT(File)
      IF ERRORCODE() THEN 
          AllDone=true
          BREAK
      END
      DO ProcessOne
   END
   IF AllDone THEN 
       0{PROP:Timer}=''
       DO EndProcessing
   ELSE
       ! Update Progress Bar code
   END
    !Timer event ends so other events can process

I dont know what API the Clarion Yield is using. It might be this one
SwitchToThread function (processthreadsapi.h) - Win32 apps | Microsoft Docs
the easy way to find out would be fire up the debugger, set a breakpoint on Yield and then switch to the disassembler window and look at the Yield to see what its calling in windows.

Now you might also be interested in altering the thread priority for your app.
This is a good article on the cpu time slicing and threading etc but technical.
Processes, Threads, and Jobs in the Windows Operating System | Microsoft Press Store

Some more on multi tasking on windows
Multitasking - Win32 apps | Microsoft Docs

This explains the quantum time slice in particular
Thread Scheduling and Benchmarking (microsoft.com)

And this is the reg setting which needs a reboot before changes take effect.
HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet /
Control / PriorityControl / Win32PrioritySeparation

They can be, it depends on what you are doing in your loop. My success with Yield has been variable so like others have suggested, I disable the timer when a timer event is fired, do the work, then enable the timer again. Another way is to start a new thread when the event timer is fired but these threads can queue up if they are being blocked, paused or whatever but at least you can see all these threads queued up. And if starting a thread from the timer event, you might have to factor handling messages from the OS thats its shutting down, so subclassing a hidden window thats running on the new thread is one way to handle those situations.

It can get complicated, but a timer event ever 1ms is quite alot for low end cpu’s that are using spin disks and not alot of ram. You dont say what spec machine it is and what else is running on the machine at the same time. Some machines I’ve seen in the past have so much running, its a wonder the user cant actually use it for anything other than looking at a screen. Low spec laptops are worse than low spec desktops in this situation.

Things like AntiVirus scanning files in realtime can also add an overhead which could see threads and file writes getting queued up very quickly. So if you have some sort of file writing work taking place in the timer event, see if AV’s can be setup to ignore certain file extensions and/or certain folders, in order to remove that delay, some AV’s have this options others dont, but in my experience most people dont use that AV option and can sometimes see tps file corruptions as a result, but you dont say what sort of work is being done in the timer event, so its difficult to really say what the problem is as there could also be other factors at play.