| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
This prevents theoretical resource leak, since those threads are never joined.
Found with ThreadSanitizer.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
|
| |
|
|
|
|
|
|
|
|
| |
The ngx_thread_pool_done object isn't volatile, and at least some
compilers assume that it is permitted to reorder modifications of
volatile and non-volatile objects. Added appropriate ngx_memory_barrier()
calls to make sure all modifications will happen before the lock is released.
Reported by Mindaugas Rasiukevicius,
http://mailman.nginx.org/pipermail/nginx-devel/2016-April/008160.html.
|
| | |
|
| |
|
|
| |
No functional changes.
|
| |
|
|
|
|
| |
It's not needed for completed tasks queue since the previous change.
No functional changes.
|
| | |
|
| |
|
|
|
| |
Work around pthread_cond_destroy() and pthread_mutex_destroy() returning
EBUSY. A proper solution would be to ensure all threads are terminated.
|
| |
|
|
|
| |
Behave like POSIX semaphores. If N worker threads are waiting for tasks,
at least that number of tasks should be allowed to be put into the queue.
|
| |
|
|
|
|
| |
It's not needed for completed tasks queue.
No functional changes.
|
| |
|
