[Gluster-devel] Help on pthread library error Handling!

[Xavier Hernandez]

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 at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140422/614f8521/attachment-0001.html>