RecurringThread is probably not the right abstraction. It was designed for best-effort activities like prolongation, not for activities upon which clients depend for correctness.
- Reanimation is not really a periodic activity, if someone wants to reanimate the past, there is no reason to wait for 20 ms before starting. If the point is to yield the processor for other activities, this could/should be done in the callback.
- The
RecurringThread doesn't manage a queue (well, it does, but it's a 1-element queue) so different callers may step on each others' toes. In particular, Put stomps on the previous data in the queue.
- The only virtue of the
RecurringThread is that it can be cancelled/restarted because it uses jthread.
- Callers that need guarantees about their request being ultimately processed (because they block) need to announce themselves using the awkward
Client/Clientele API. This is only correct if all the places that may ask for a restart or call Put properly look at the Clientele.
We need some kind of a ThreadPool which is based on jthread, and whose queue is time-ordered, probably with handles to allow individual cancellation of requests.
RecurringThreadis probably not the right abstraction. It was designed for best-effort activities like prolongation, not for activities upon which clients depend for correctness.RecurringThreaddoesn't manage a queue (well, it does, but it's a 1-element queue) so different callers may step on each others' toes. In particular,Putstomps on the previous data in the queue.RecurringThreadis that it can be cancelled/restarted because it usesjthread.Client/ClienteleAPI. This is only correct if all the places that may ask for a restart or callPutproperly look at theClientele.We need some kind of a
ThreadPoolwhich is based onjthread, and whose queue is time-ordered, probably with handles to allow individual cancellation of requests.