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

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库的用户不必费心.
>所有用户都在做一次工作,而不是让每个用户都实现自己的线程安全.

那么,捕获量在哪里?

最佳答案
它已经完成(在ncurses 5.7,November 2008发布),但使用不多.例如,请参见curs_threads手册页.它不是默认配置中的功能,因为它

>更改ABI(应用程序二进制接口),和
>对标准变量的使用方式添加了一些限制.

转载注明原文:thread-safety – 为什么没有人编写ncurses库的线程安全分支? - 代码日志