Problem: if the limiter is blocked due to a client flow, and the client then issues a qos = 0, we can't have the limiter exiting. Thus limit needs to become a call, plus associated changes. Note that we *have* to know whether or not the limiter is about to stop - if we just wait for the exit signal then there's a race with a new qos setting being sent to an expiring limiter and the limiter thus getting lost. Also, the channel *must* be responsible for telling the queues to forget the limiter, otherwise again there's a race between a new limiter starting up and telling the queues about it, and the old limiter dying and telling the queues they're unlimited. This is why the limit_queues function cannot be moved into the limiter - the channel must drive this.

0 files changed, 0 insertions, 0 deletions