[prev in list] [next in list] [prev in thread] [next in thread]
List: gnulib-bug
Subject: Re: Lock module improvement
From: Bruno Haible <bruno () clisp ! org>
Date: 2008-07-29 22:00:50
Message-ID: 200807300000.50358.bruno () clisp ! org
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic