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: Bruno Haible
Subject: Re: [PATCH]: gl_recursive_lock_init issue with pthread backend
Date: Fri, 7 Dec 2007 12:17:34 +0100
User-agent: KMail/1.5.4

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

In all cases I know of, a lock initialization is nothing more than a memcpy.
I'm not worried about it.

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

Yes, but this is (or ought to be) handled inside the pthread_* functions.

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

The glibc pthread_mutex_lock() calls assert() at 8 places.

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

glibc's intl/* code simply ignores this possibility. gnulib's 'lock' module
is safer than this, it at least checks the return value.

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

That's an argument I can buy. I assume that such cleanup handlers are
registered as C++ exceptions on the stack, or via atexit(). Can you
suggest what to do instead of abort()?

Bruno





reply via email to

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