为什么 POCO 选择在 OSX 上使用 Posix 信号量？
我是 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 信号量无法提供的。
I am a new bee to MAC/OSX. I am working on Titanium a cross platform runtime, which uses POCO library for most of the portable C++ API. I see that POCO uses POSIX semaphore for its NamedMutex implementation on OSX as opposed to SysV semaphore that it is using for few other *NIX.
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
}
For few searches, I see that SysV sem_* API is supported on OSX as well: http://www.osxfaq.com/man/2/semop.ws. Any Idea, why POCO developers chose to use POSIX API on OSX?
I am particularly intested in SEM_UNDO functionality in the above call, which the POSIX semaphores can't give.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于部分 POCO 开发人员来说，这似乎是相当武断的决定：这两个信号量与 Windows 的命名信号量并不真正匹配（它们显然是在之后精心设计的）。 POSIX 上没有信号量，它有自己的类似于文件系统的符号命名空间。 （SysV sems 的命名空间由整数 id 组成，但没有符号名称。）
如果发布的代码确实来自该库，我只能建议停止依赖该库来实现可移植性。好吧，至少对于信号量，您显然已经开始自己的实现了。
编辑1。检查 Windows 中信号量的实现方式。此类库使用 Windows 的临界区是很常见的。那么 POSIX sem_t 是正确的匹配。仅当信号量被多个进程访问时才需要 SEM_UNDO - 它不适用于线程。即当进程崩溃时会发生撤消。尽管在 Linux 上他们使用 SysV 的事实相当令人不安。 SysV 信号量是全局的，因此其数量受到操作系统限制（可以在运行时更改） - 而 sem_t 信号量是进程本地的，只是私有内存中的一个结构，仅受进程可以使用的本地内存量的限制。分配。
PS 不情愿。真正的原因可能是 POCO 主要开发发生在 Windows 上（通常是“可移植库”；它们“可移植到 Windows”，也就是说试图使 *NIX 看起来像 Windows）。 UNIX 实现通常是事后才想到的，是由那些在几米外看到终端屏幕并且从未进一步阅读手册页和函数原型的人实现的。这是我过去使用过几个这样的“便携式图书馆”的个人经历。
That seems to be rather arbitrary decision on part of POCO developers: both semaphores do not really match the Windows' named semaphores (after which they are apparently crafted). There is no semaphore on POSIX which has its own symbolic namespace akin to a file system. (SysV sems have namespace made of integer ids, but no symbolic names.)
If the posted code really comes from the library, I can only advise to stop relying on the library for portability. Well, at least with the semaphores you apparently have to start your own implementation already.
Edit1. Check how the semaphores are implemented for Windows. It's common for such libraries to use Windows' critical sections. Then the POSIX sem_t is a proper match. You need SEM_UNDO only if the semaphore is accessed by several processes - it doesn't work for threads. I.e. undo happens when the process crashes. Though the fact that on Linux they use SysV is quite troubling. SysV semaphores are global and thus have OS limit (can be changed on run-time) on their number - while sem_t semaphores are local to the process, are just a structure in private memory and are limited only by the amount of local memory process can allocate.
P.S. Reluctantly. Real reason might be that the POCO main development takes place on Windows (usual to the "portable libraries"; they are "portable to Windows" so to say trying to make *NIX look like Windows). UNIX implementation is very very often an afterthought, implemented by somebody who has seen terminal screen from few meters away and never read the man page further the function prototype. That was my personal experience with couple of such "portable libraries" in the past.