I can use suspend on a thread, and a timer event (or other event) to resume it again. This works OK. Doing a bit of new development I’ve been trying, instead, to have the thread sleep itself with the notion that it can then be resumed by my other event or will continue anyway when the sleep time expires.
I would have thought these two approaches ought to be equivalent, as implied by the doc for resume: “Wakes up a thread that was suspended because of a call to Suspend or is sleeping because of a call to Sleep” is what it says (it doesn’t mention WakeEarly). What I find with sleep is that the resume works sometimes, but if I add a bit of code to another part of the app, the timings change and the sleep tends to run its term. I also tried adding WakeEarly to the sleep call without success.
Should I give up on that approach and always use suspend with a timer? And if so, why?
If a thread resume occurs while the thread is running, is that just ignored, or stored up for when the next suspend occurs? It seems to be ignored.
Suspending a thread tells it to wait until you later call Resume.
Calling Sleep, you specify the amount of time that you want the thread to sleep.
[quote=415242:@Greg O’Lone]Suspending a thread tells it to wait until you later call Resume.
Calling Sleep, you specify the amount of time that you want the thread to sleep.[/quote]
Then should I make a documentation change request Feedback case?
Changed to what? You can only resume a thread that is sleeping or suspended as the docs say. Resuming a thread that is running has no effect. After all, if it is running there is nothing to resume.
For resume, changed to no longer say that resume will cancel a sleep, and for sleep to say that, without WakeEarly, a sleep will run its full time period even if the thread is resumed. At least that would appear to be the implication of what Greg said earlier. And, it’s borne out by my own experience; I changed the appropriate sleeps to suspends, and had no problems since (I just have to instance a timer now to add timeouts to the websocket read operations as I’ve already done for the other SSLsockets I read from).
Greg said Resume is ignored if a thread is running, nothing more. In my tests, a sleeping thread starts back up when Resume is called on it. If you have examples that demonstrate otherwise, get them in Feedback so we can see if this is a bug or something else.