Re: [PATCH]: gl_recursive_lock_init issue with pthread backend

[Bruno Haible]

Yoann Vandoorselaere wrote:
> > I don't know what a better handling
> > of pthread_* function failures could look like. What do you propose?
> 
> Any reason why you don't simply return error values returned by
> pthread_* functions (which should set errno appropriately), and let the
> caller possibly handle it?

What could the caller do to "handle" it? Say, it needs access to a data
structure shared among threads, and other threads are already running. In
this situation, the function which should take the data structure's lock
fails. What can the program do?
  - Proceed without locking? Good joke.
  - Put the current thread into an endless sleep(), and let the other
    threads survive as they can? Well, the other threads will likely wait
    on the sleeping thread at some point (because every thread has a purpose
    of some kind, in a real application).
  - Throw a C++ exception? In a C program, which does not install a handler
    for it, this will call ::terminate(). Not much different from abort().
  - Give an error message? This is what the abort() does.

Really, initializing, taking and releasing locks are so primitive operations
that they *must* not fail. It's like longjmp() or 'goto' failing.

Bruno