Hi Kotresh, I have had to make a similar decision in the implementation of libgfsys [1]. 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. Xavi [1] http://review.gluster.org/#/c/7521 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 > process. > > > Thanks and Regards, > Kotresh H R > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
