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