Peter, Thanks a million for this test case. It finally let me find what I think was the problem.
Here is an expanded checkin message to explain the fix. fix notifier problem, perhaps finally at last. Here is what was happening. fast_reschedule() does _pass += _stride. fast_schedule() looks at the first _pass scheduled on the router, OR USES 0 IF THERE IS NO TASK ON THE ROUTER AT THE MOMENT. Result: if a task is schedule()d while the router is empty, before a fast_reschedule(), the newly schedule()d task will have a really tiny _pass (like based on 0), and the new task will have a much larger _pass -- so large as to be negative. Then the new task will win for a long time, even though the schedule()d task is actually sitting around scheduled. Better plan: keep track of the current _pass in RouterThread. Thanks to Peter De Cleyn for an example. Anonymous CVS is updated. Does it work for you? Eddie Peter De Cleyn wrote: > Forgot to add in my previous mail, that the problem does not occur > when using a SimpleQueue. I therefor think that the reason for this > behaviour should be found within the notifier mechanism. I likewise > discussion was already covered in previous posts and updates, but it > seems the updates made then did not solve it all. > > Peter De Cleyn > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
