Some thread-unsafe functions of our codebase appear very down in the call stack, which can be hard to notice (or avoid). Thus they are sometimes used in threaded code unsafely. In this series we add pthread_once() to compat/win32/ and use it in conjunction with pthread_key to make a subset of the said functions thread-safe. As a next step, I would love to make [warning|error|die]_errno() thread-safe as well. strerror() is not safe on *nix, and there are some thread functions today that call these (although the actual risk of a race condition must be very small...) My idea was to implement a xstrerror() wrapper which calls the appropriate thread-safe function (dependant on the OS), or even call strerror() itself but holding a lock to copy the result for a local buffer (which should be OK as we don't expect contention in strerror). We could also set a thread local buffer array, as in the second patch of this series, to excuse callers from allocating/freeing memory. One concern with this idea is the risk of an infinite recursion if xstrerror() or any of its childs call [warning|error|die]_errno(). However, if we are only using strerror() and pthread_*() within the wrapper, there should be no problem, right? Has anyone thought of other problems with this approach? Finally, should such change also come with a coccinelle patch to replace usages of strerror() with xstrerror()? Or better not, as the change would be too big? Matheus Tavares (2): compat/win32/pthread: add pthread_once() hex: make hash_to_hex_algop() and friends thread-safe compat/win32/pthread.c | 22 +++++++++++++++++++++ compat/win32/pthread.h | 5 +++++ hex.c | 45 ++++++++++++++++++++++++++++++++++++++---- thread-utils.c | 11 +++++++++++ thread-utils.h | 6 ++++++ 5 files changed, 85 insertions(+), 4 deletions(-) -- 2.26.2
