爲什麼POCO選擇使用OSX的Posix信號量？

我是MAC/OSX的新蜜蜂。我正在研究Titanium跨平臺運行時，它爲大多數可移植的C++ API使用POCO庫。我發現POCO在OSX上爲其NamedMutex實現使用POSIX信號量，而不是SysV信號量，它在其他* NIX中使用。爲什麼POCO選擇使用OSX的Posix信號量？

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 
}

對於一些搜索，我看到的SysV爲sem_ * API的支持OSX，以及：http://www.osxfaq.com/man/2/semop.ws。任何想法，爲什麼POCO開發人員選擇在OSX上使用POSIX API？

我特別在上面的調用中使用了SEM_UNDO功能，這是POSIX信號量不能給出的。

來源

2010-08-10 wanderer

我想冒險猜測，因爲OSX植根於BSD，它在SysV發生之前從UNIX樹分支出來，因此對於OSX POSIX可能比SysV更接近本機。 – m1tk4 2010-08-13 19:07:27

任何想法，爲什麼POCO開發人員選擇在OSX上使用POSIX API？

對於POCO開發者來說，這似乎是一個相當武斷的決定：兩個信號燈都不能真正匹配Windows的命名信號量（之後它們顯然是精心設計的）。 POSIX上沒有信號量，它有自己的符號名稱空間，類似於文件系統。（SysV sems的命名空間由整型id組成，但沒有符號名稱。）

如果發佈的代碼確實來自庫，我只能建議停止依賴庫來實現可移植性。那麼，至少在信號量方面，你顯然已經開始自己的實現了。

編輯1。檢查信號量是如何針對Windows實現的。這些庫使用Windows的關鍵部分是很常見的。然後POSIX sem_t是一個合適的匹配。只有在信號量被多個進程訪問時才需要SEM_UNDO - 它不適用於線程。即當進程崩潰時，撤消會發生。儘管在Linux上他們使用SysV的事實相當令人擔憂。 SysV信號量是全局的，因此操作系統的限制（可以在運行時更改）其數量 - 而sem_t信號量是進程本地的，只是私有內存中的結構，並且僅受限於本地內存進程的數量分配。

P.S.勉強。真正的原因可能是POCO的主要開發發生在Windows上（通常是「便攜式庫」;它們「可移植到Windows」，所以試圖使* NIX看起來像Windows）。 UNIX實現往往是事後纔想到的，由幾米之外的人看到了終端屏幕，並且從未讀過函數原型的更多手冊頁。這是我過去對幾個這樣的「便攜式圖書館」的個人體驗。

來源

2010-08-21 11:00:15 Dummy00001

是的，對於我使用的用例，我需要信號量跨進程訪問，並在退出時進行清理（包括崩潰） – wanderer 2010-08-23 07:46:29

爲什麼POCO選擇使用OSX的Posix信號量？

回答

相關問題