On Mon, Nov 12, 2012 at 10:40 AM, Poul-Henning Kamp <[email protected]>wrote:
> -------- > In message <[email protected]>, > Mart > in Blix Grydeland writes: > >This is to give persistent stevedores a chance to clean up their ban > >lists without having to worry about the lists changing under them > >(normally the ban callbacks are called under the ban mutex, but not so > >during exit). > > I don't have a problem with the idea, but I don't like having BAN_Insert() > return a failure we don't know how to handle. I think BAN_Insert() should > take ownership of the ban even when it fails, but returning a status code > is probably a good idea, provided it gets used for something somewhere. > Changed to make BAN_Insert() always take ownership of the ban, freeing it on failure. BAN_Insert() will still return the status code. > > I think it should be used in the CLI::ban case, so that a > cluster-controller > can keep track of which bans have been entered on which varnish instances. > CLI will get the error message. > > >Also remove the duplicate drop tail bans code. That is now only done > >in the main thread loop. > > This breaks r01030.vtc so it should probably be done in its own commit. > This has been moved to a separate commit. Though I do not see how the change affects r01030.vtc, nor have I been able to make that test case fail. Martin -- <http://varnish-software.com>*Martin Blix Grydeland* Senior Developer | Varnish Software AS Cell: +47 21 98 92 60 We Make Websites Fly!
_______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
