Re: Lock module improvement

[Bruno Haible]

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
  http://lists.gnu.org/archive/html/bug-gnulib/2007-12/msg00002.html
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

   gl_thread_mutex_lock(&mutex);

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.)

Bruno