Willy Tarreau 082b62828d BUG/MEDIUM: init/threads: provide per-thread alloc/free function callbacks ... We currently have the ability to register functions to be called early on thread creation and at thread deinitialization. It turns out this is not sufficient because certain such functions may use resources that are being allocated by the other ones, thus creating a race condition depending only on the linking order. For example the mworker needs to register a file descriptor while the pollers will reallocate the fd_updt[] array. Similarly logs and trashes may be used by some init functions while it's unclear whether they have been deduplicated. The same issue happens on deinit, if the fd_updt[] or trash is released before some functions finish to use them, we'll get into trouble. This patch creates a couple of early and late callbacks for per-thread allocation/freeing of resources. A few init functions were moved there, and the fd init code was split between the two (since it used to both allocate and initialize at once). This way the init/deinit sequence is expected to be safe now. This patch should be backported to 1.9 as at least the trash/log issue seems to be present. The run_thread_poll_loop() code is a bit different there as the mworker is not a callback, but it will have no effect and it's enough to drop the mworker changes. This bug was reported by Ilya Shipitsin in github issue #104.		2019-05-22 14:59:08 +02:00
..
common	MINOR: threads: add a timer_t per thread in thread_info	2019-05-22 11:50:48 +02:00
import
proto	MINOR: connection: report the mux names in "haproxy -vv"	2019-05-22 11:50:48 +02:00
types	BUG/MEDIUM: init/threads: provide per-thread alloc/free function callbacks	2019-05-22 14:59:08 +02:00