I found that threads in Windows are a little bit more problematic, but can’t find an acceptable solution to this problem:
A Canvas subclass instantiate a Thread which builds thumbnails of pictures to be shown in the Canvas.
The same subclass instantiate a Timer which periodically check the thumbnails and update the Canvas.
The timer is set to Multiple when the thread starts and then is set to Off from the thread run event just before finishing the work.
Theoretically it should be a no brain problem and in fact it works very well on OS X. The UI remains responsive and the Canvas update.
On Windows it doesn’t work: the thread starts, and the timer Action is NEVER called.
What happens, is that the thread hijack completely the CPU and then turn off the timer when it finish the work. As a result the UI is not updated and all other operations are blocked. It behave like code not running in a thread.
To be noted: the thread is set to the lowest priority (1) and the timer period is set to 100.
Try setting the timer’s period higher, like 500 maybe. At 100 milliseconds you may be firing the process too often and not giving the thread any down-time to allow anything else to happen.
Sounds like the opposite problem, though I too would recommend a higher setting on the timer. You may need to explicitly yield time from the thread by calling app.YieldToNextThread every X microseconds or ticks. And yes, you are correct. Threads on Windows do not yield smoothly. I actually prefer it this way, but it is less user friendly.
I think I’ve found where the problem lie, but I don’t have solution since seems a bug to me.
The fact is my thread.Run event has loop to see if some thumbnail has to be built and then exit when all are done.
When I add pictures, I check if the thread is running or not. If it’s not running I start it again with Run method.
Here is the blocker. Seems like running the thread again will hog the CPU.
In fact, if I set to NIL the thread and instantiate it again, then run, all works as expected.
This is a bug I think.