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
