-------- 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. 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. >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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
