[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lock module improvement

From: Bruno Haible
Subject: Re: Lock module improvement
Date: Wed, 30 Jul 2008 00:00:50 +0200
User-agent: KMail/1.5.4

Yoann Vandoorselaere wrote:
> Would it be okay if contrary to the current lock.h module (which define
> the various gl_lock_ functions as macros), I use real function? 

Sure. For code that you write, you decide how it's written. I have no
requirements coming from gettext or anywhere else.

> Additionally, your current lock.h code still make use of abort() which
> I'm reluctant to see in library code. Would you agree to propagate the
> error return in case of problem?

We started to discuss this already in the thread starting at
You pointed out that e.g. pthread_mutex_lock() can fail for various reasons.
I agree that in theory it could be nice if the applications can "handle" it.
But there are not many possible ways to "handle" such situations, And if
you expect a programmer to write

   assert (pthread_mutex_lock(&mutex) == 0);

instead of


I bet that most of them will drop the error checking out of laziness - like
so many people ignore the return value of 'printf' and 'fprintf'.

It's a tradeoff between ease-of-use of the macros and theoretical correctness.

Can you propose a reasonable compromise? (Just changing the existing macros
to return a value instead of checking the return value is not good, because
it would make all existing code that uses the macros less reliable.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]