fdl: fix race during initialization

There was a race between fdl_worker starting to run and setting
this->private in fdl_init.  This should never happen on a
multiprocessor, since the new thread should start on a different core
and creating it there should take many times longer than getting from
pthread_create to the end of fdl_init on the original core.  The only
way it seems likely is if the new thread is started on the same core
that's already in fdl_init, and the new thread preempts the old, which
many would consider broken . . . but there are plenty of broken thread
implementations and it's hardly surprising that glibc has one.  Still,
it's a race and it did show up in regression tests a few times, so it
needs to be fixed.

Change-Id: Ifa5b0ae1ec111860f0d3f55a98aa2b8f2cef84ca
Signed-off-by: Jeff Darcy <jdarcy@redhat.com>
Reviewed-on: http://review.gluster.org/13674
Smoke: Gluster Build System <jenkins@build.gluster.com>
NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
CentOS-regression: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>

0 files changed, 0 insertions, 0 deletions