[Click] strange LinkUnqueue behaviour

[Eddie Kohler]

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
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click