bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH]: gl_recursive_lock_init issue with pthread backend


From: Yoann Vandoorselaere
Subject: Re: [PATCH]: gl_recursive_lock_init issue with pthread backend
Date: Tue, 04 Dec 2007 10:25:56 +0100

Le mardi 04 décembre 2007 à 09:46 +0100, Bruno Haible a écrit :
> 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?

I'm worried about lock initialization. If initializing a mutex fail, the
application should be allowed to handle it gracefully. 

Some applications provide threads support only to improve performance on
SMP capable hardware. If threads initialization fail, they should be
given a chance to revert to single thread capability.

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

I agree that you cannot do much on critical[0] locking / unlocking
error, but you should let the application in control of the way it is
going to handle the issue (example: there might be important cleanup to
perform for persistant stored data to remain usable on next run).

I wouldn't like standard glibc pthread_mutex_lock() to call abort() for
me, would you? 

[0] POSIX define that pthread_mutex_lock() will return EAGAIN if the
"maximum number of recursive locks for mutex has been exceeded.", this
kind of error might be expected by the programmer.

-- 
Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies
Tel: +33 (0)8 70 70 21 58                  Fax: +33(0)4 78 42 21 58
http://www.prelude-ids.com





reply via email to

[Prev in Thread] Current Thread [Next in Thread]