[Gluster-devel] Help on pthread library error Handling!
xhernandez at datalab.es
Tue Apr 22 13:40:13 UTC 2014
I have had to make a similar decision in the implementation of libgfsys . Looking at
what can fail in these function calls, it's clear that only a bug (i.e. a call to
pthread_mutex_lock() with an uninitialized mutex or a bad pointer, or bad designed
code) can generate an error. For this reason I decided to abort (using asserts) if this
kind of calls fail. Anyway this shouldn't happen on released code (all these bugs should
have been detected and corrected before releasing a version). Handling a failed
pthread_mutex_lock() call can be tricky in some places.
However there are still some calls that can fail for other reasons not related to bugs,
like pthread_mutex_init() if there aren't enough resources. These calls need to be
handled correctly and propagate the error.
On Tuesday 22 April 2014 08:37:36 Kotresh Hiremath Ravishankar wrote:
> Hi All,
> I am using pthread_mutex_lock in changelog translator which is part of brick
> process (glusterfsd). I see that pthread errors are not being catched and
> handled in current gluster code except in qemu where it is aborted. What is
> the correct way to handle the error when pthread library routines fail in
> gluster. Just logging the error and continuing would lead to data
> corruption and deadlocks. Aborting the process will abort whole glusterfsd
> Thanks and Regards,
> Kotresh H R
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel