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