- A thread returns with one or more messages still in its input queue, and:
- The thread has not done anything to terminate itself, such as call ct_exit() or ct_fatal_error().
The Old Way
If the thread had called ct_wait(),, the scheduler would put the thread on a list of sleeping threads, and run it again only when the thread received an event. Otherwise it would enqueue the thread at its normal priority, or at a lower priority if the thread had called ct_penalize().This policy would create problems for a thread that processed only a single input message and then put itself to sleep. If it received more than one message it would process only the first one, unless some other event occurred later to wake it up. Even if it eventually processed all the messages, the timing would likely be off.
In order to avoid this problem, the thread would have to either loop through all its input messages or be more careful about when to go to sleep. Either approach would create annoying complications.
The New Way
In this situation, the new algorithm enqueues the thread for execution again at the highest priority, even if it has called ct_wait() or ct_penalize().As a result the thread's logic can be simpler. It can process one message at a time and let the scheduler take care of the looping.
Possible Problems
In most cases, code written for the earlier algorithm will still work just as it did before. You can still loop through the input queue, or you can call ct_wait() only if the input queue is empty.However, it is possible that some existing code relies on the ability to put a thread to sleep even when tbere are still messages in its input queue. Such an application will break if you upgrade to version 2.3 or above.
I regard this danger as unlikely. On request, however, I can make the new behavior subject to a compile-time macro, so that you can restore the new behavior if you need it.
Home