thread-safety - 为什么没有人编写 ncurses 库的线程安全分支？

Question

NCurses 似乎是一个流行的库。它的弱点之一是它不是线程安全的。将共享资源包装在互斥锁中应该不难。

是否有特定原因，为什么没有人启动线程安全分支？(法律问题，引入平台依赖性，......)

编辑:我指的不是 use_screen 或 use_window 函数。这些显然要求用户更改其基于 NCurses 的代码。应该可以在 NCurses 本身的共享资源中添加互斥锁，并且所有访问函数在对窗口执行某些操作之前获取互斥锁。我在 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
}

• 这不依赖于 C++11 标准。
• 这与旧的编译器兼容。 (但那时没有线程安全。)
• 进行修改的时间不应超过一两天。
• 这满足了对线程安全 NCurses 的需求。
• NCurses 库的用户不必费心。
• 这项工作为所有用户一次性完成，而不是让每个用户实现自己的线程安全。

那么，问题在哪里呢？

Answer 1

它已经完成了(在 ncurses 5.7 中，发布了 November 2008 )，但用得不多。查看curs_threads例如手册页。它不是默认配置中的功能，因为它

• 更改 ABI(应用程序二进制接口(interface))，以及
• 对如何使用标准变量添加了一些限制。