Hi Lorenzo,
No, this change seems perfectly reasonable. And in fact I'm going to check it
in to mainline. However the only reason you had this problem was that you set
a large BURST value -- you could also just leave BURST at 1, the default.
Eddie
Lorenzo Bianconi wrote:
> Hi all,
>
> I am using Click in kernel module to implement a system where a given node
> manages the transmission of N other nodes.In particular, in the node
> configuration, to stop and to restart the packet transmission I am using an
> unqueue element which is activated and deactivated by another element. I have
> noticed when I unschedule the unqueue task (setting the unqueue class
> attribute _active to false), the element continues to pull/push packets until
> it reaches the _burst threshold. In order to render the unqueue element more
> responsive when it has been unscheduled, I have modified in this way the
> run_task class member function (I have highlighted in red the modification):
>
> bool
>
> Unqueue::run_task(Task *)
> {
> if(!_active)
> return false;
>
> int worked = 0;
> while ((worked < _burst) && _active) {
> if (Packet *p = input(0).pull()) {
> worked++;
> output(0).push(p);
> } else {
> if(!_signal) {
> _count += worked;
> return worked > 0;
> }
> break;
> }
> }
>
> _task.fast_reschedule();
> _count += worked;
> return worked > 0;
> }
>
> Do you think it is correct or maybe it could trigger problems??
>
> Thanks
>
> Kind regards
>
> Lorenzo
>
> _______________________________________________
> 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
