[Click] Notifications

[Eddie Kohler]

For what it's worth, I've checked in a change that will result in more 
Queues being able to share a Notifier -- but there's still a limit.

It may be that the "bitwise" Notifier mechanism, which attempts to be 
fast, is actually a bad optimization -- that something like "check every 
byte in this list" would be just as fast.  I'd be interested in some 
numbers, if anyone wants to work on such a project.

Eddie


Lars Bro wrote:
> Hi, 
> 
> In the following Click script:
> 
> 
> s::PrioSched;
> 
> Idle -> Queue -> [0]s;
> Idle -> Queue -> [1]s;
> Idle -> Queue -> [2]s;
> Idle -> Queue -> [3]s;
> Idle -> Queue -> [4]s;
> Idle -> Queue -> [5]s;
> Idle -> Queue -> [6]s;
> Idle -> Queue -> [7]s;
> Idle -> Queue -> [8]s;
> Idle -> Queue -> [9]s;
> Idle -> Queue -> [10]s;
> Idle -> Queue -> [11]s;
> Idle -> Queue -> [12]s;
> Idle -> Queue -> [13]s;
> Idle -> Queue -> [14]s;
> Idle -> Queue -> [15]s;
> // Idle -> Queue -> [16]s;
> 
> s->Unqueue -> Print -> Discard;
> 
> This example should do nothing at all.
> If I enable input # 16, the Unqueue element starts looping. It seems
> that the Unqueue element believes that there is a reason for waking up
> when the PrioSched element has more than 16 inputs. The PrioSched
> correctly finds out that none of the signals are active, and returns
> nothing. The Unqueue expects to be put to sleep, otherwise it will loop
> until it gets _bursts packets.
> 
> Yours,
> Lars Bro
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click