Question

我是MAC / OSX的新宠。我正在为Titanium开发一个跨平台运行时，它使用POCO库来处理大多数可移植的C ++ API。我看到POCO在OSX上使用POSIX信号量用于其NamedMutex实现，而不是用于少数其他* NIX的SysV信号量。

bool NamedMutexImpl::tryLockImpl()
{
#if defined(sun) || defined(__APPLE__) || defined(__osf__) || defined(__QNX__) || defined(_AIX)
 return sem_trywait(_sem) == 0;
#else
 struct sembuf op;
 op.sem_num = 0;
 op.sem_op  = -1;
 op.sem_flg = SEM_UNDO | IPC_NOWAIT;
 return semop(_semid, &op, 1) == 0;
#endif
}

对于少数搜索，我发现OSX上也支持SysV sem_ * API：http://www.osxfaq.com/man/2/semop.ws。任何想法，为什么POCO开发人员选择在OSX上使用POSIX API？

我特别关注上述调用中的SEM_UNDO功能，POSIX信号量无法给出。

Answer 1

任何想法，为什么POCO开发人员选择在OSX上使用POSIX API？

对于POCO开发人员而言，这似乎是相当随意的决定：两个信号量都不能与Windows命名的信号量相匹配（之后它们显然是精心设计的）。 POSIX上没有信号量，它有自己的符号命名空间，类似于文件系统。（SysV sems的命名空间由整数id组成，但没有符号名称。）

如果发布的代码确实来自库，我只能建议停止依赖库来实现可移植性。好吧，至少在信号量方面，你显然必须开始自己的实现。

<强> EDIT1 即可。检查如何为Windows实现信号量。这些库通常使用Windows的关键部分。然后POSIX sem_t是一个正确的匹配。只有当多个进程访问信号量时才需要SEM_UNDO - 它不适用于线程。即当进程崩溃时撤消。虽然在Linux上使用SysV这一事实令人非常麻烦。 SysV信号量是全局的，因此在数量上有操作系统限制（可以在运行时更改） - 而sem_t信号量是进程的本地信号，只是私有内存中的结构，并且仅受本地内存进程量的限制分配

P.S。勉强。真正的原因可能是POCO的主要开发发生在Windows上（通常用于“便携式库”;它们“可移植到Windows”，所以说试图让* NIX看起来像Windows）。 UNIX实现通常是事后的想法，由一些人在几米之外看过终端屏幕并且从未在函数原型中进一步阅读手册页来实现。这是我过去亲自体验过几个这样的“便携式图书馆”。

为什么POCO选择将Posix信号量用于OSX？

1 个答案: