[Top][All Lists]
[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