| commit | 9395d958d6d5445082a369c54477e5f295df1974 | |
| author | Volker Lendecke <vl@samba.org> | |
| Mon, 29 Aug 2016 09:35:39 +0000 (29 11:35 +0200) | ||
| committer | Jeremy Allison <jra@samba.org> | |
| Tue, 30 Aug 2016 02:06:20 +0000 (30 04:06 +0200) | ||
| tree | f9aa04aa94561c2a9202ce906a978c02bb9c2779 | treesnapshot (tar.gz zip) |
| parent | e7e18c432de41bb6f5a1a7b8c3d3bd245b9380df | commitdiff |
pthreadpool: Signal job completion without the pool mutex
This essentially reverts 1c4284c7395f23. We now call an alien function from
within pthreadpool, and we should not hold a mutex during that call. The alien
function could (and pthreadpool_tevent_job_signal actually does) lock a mutex.
We can't guarantee proper lock ordering here, so in theory we could deadlock. I
haven't seen it in the wild yet, but I could imagine that both _parent pieces
in pthreadpool and tevent could trigger such a deadlock.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Aug 30 04:06:20 CEST 2016 on sn-devel-144
This essentially reverts 1c4284c7395f23. We now call an alien function from
within pthreadpool, and we should not hold a mutex during that call. The alien
function could (and pthreadpool_tevent_job_signal actually does) lock a mutex.
We can't guarantee proper lock ordering here, so in theory we could deadlock. I
haven't seen it in the wild yet, but I could imagine that both _parent pieces
in pthreadpool and tevent could trigger such a deadlock.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Aug 30 04:06:20 CEST 2016 on sn-devel-144
| source3/lib/pthreadpool/pthreadpool.c | diffblobblamehistory |