tree eec6ddf9db14d8fb8e53a45752e3a93f4f795cb1
parent 209d02a257d795c3b682c858277e7cbc738aefdf
author Emeric Brun <ebrun@haproxy.com> 1506517178 +0200
committer Willy Tarreau <w@1wt.eu> 1509454710 +0100
encoding latin1

MAJOR: threads/task: handle multithread on task scheduler

2 global locks have been added to protect, respectively, the run queue and the
wait queue. And a process mask has been added on each task. Like for FDs, this
mask is used to know which threads are allowed to process a task.

For many tasks, all threads are granted. And this must be your first intension
when you create a new task, else you have a good reason to make a task sticky on
some threads. This is then the responsibility to the process callback to lock
what have to be locked in the task context.

Nevertheless, all tasks linked to a session must be sticky on the thread
creating the session. It is important that I/O handlers processing session FDs
and these tasks run on the same thread to avoid conflicts.