Re: [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

> address@hidden

> https://lists.nongnu.org/mailman/listinfo/gluster-devel