thread safety - Why has no one written a threadsafe branch of the ncurses library?

Question

NCurses appears to be a popular library. One of its weaknesses is, that it is not threadsafe. It should not be hard to wrap shared ressources in mutexes.

Is there a specific reason, why noone has started a threadsafe branch? (Legal issues, introducing a platform dependency, ...)

Edit: I do not mean the use_screen or use_window functions. These apparently require the user to change his NCurses-based code. It should be possible to add a mutex to the shared resources within the NCurses itself, and all accessing functions acquire the mutex before doing something with the window. I am imagining something like this within NCurses:

#if __cplusplus >= 201103L
#include <mutex>
#define THREADSAFE
#endif
...
#ifdef THREADSAFE
std::recursive_mutex  mxCurscr;
#endif
...
int doupdate(void)
{
#ifdef THREADSAFE
mxCurscr.lock();
#endif
... // <-- Access the screen here.
#ifdef THREADSAFE
mxCurscr.unlock()
#endif
}

• This does not rely on anything but the C++11 standard.
• This is compatible with older compilers. (But no threadsafety then.)
• It should not take more than one or two days to make the modifications.
• This satisfies the demand for a threadsafe NCurses.
• The user of the NCurses library will not have to bother.
• The work is being done one time for all users, instead of having every user implementing its own thread-safety.

So, where is the catch?

Answer 1

It's already been done (in ncurses 5.7, released November 2008), but not much used. See the curs_threads manual page for instance. It is not a feature in the default configuration because it

• changes the ABI (application binary interface), and
• adds some restrictions on how standard variables are used.