| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were a few random places where 0 was being used as a null pointer
constant.
We have a NULL macro for this very purpose, use it.
There is also some interest in actually deprecating the use of 0 as a
null pointer constant in C.
This was found with -Wzero-as-null-pointer-constant which was enabled
for C in GCC 15 (not enabled with Wall or Wextra... yet).
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059>
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
