Volker Lendecke e84521dc44 lib: Fix a pthreadpool race condition ... Yes, there is one.... I've seen two flaky builds on sn-devel with pthreadpool after the coverity checks went in. They were in the ret = pthread_mutex_unlock(&pool->mutex); assert(ret == 0); in pthreadpool_parent() and pthreadpool_child(). No idea what that was, I could not really reproduce that. A build attempt on FreeBSD also gave an erratic error, this time it was an EINVAL in ret = pthread_mutex_lock(&pool->mutex); assert(ret == 0); pthreadpool_parent(). EINVAL means that the mutex is not a proper mutex. What happened: Someone (a detached thread) does the pthreadpool_free behind our back, while we are in pthreadpool_parent, preparing the fork. Unfortunately the mutex was already destroyed before we came to lock it. The fix is simple: Remove the obsolete struct pthreadpool from the linked list before the mutex is destroyed. Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Ralph Boehme <slow@samba.org>		2016-10-17 22:34:20 +02:00
..
Makefile
pthreadpool_pipe.c	pthreadpool_pipe: Implement EBUSY for _destroy	2016-10-05 00:06:21 +02:00
pthreadpool_pipe.h	lib: Add pthreadpool_pipe	2016-08-24 01:33:48 +02:00
pthreadpool_sync.c	lib: add job data to to callback	2016-08-24 01:33:48 +02:00
pthreadpool_tevent.c	pthreadpool_tevent: Drop running jobs on talloc_free	2016-10-05 00:06:22 +02:00
pthreadpool_tevent.h	lib: Add pthreadpool_tevent	2016-08-24 01:33:48 +02:00
pthreadpool.c	lib: Fix a pthreadpool race condition	2016-10-17 22:34:20 +02:00
pthreadpool.h	pthreadpool: Use detached threads	2016-10-05 00:06:21 +02:00
tests.c	pthreadpool: Fix CID 1373620 Unchecked return value from library	2016-10-14 21:45:08 +02:00
wscript_build	lib: Add pthreadpool_tevent	2016-08-24 01:33:48 +02:00