El 13/02/2012 18:08, Davidson, Josh escribió:
Thanks for the information. I did briefly peek at the code and when I saw WaitForSingleObject, I assumed the handle was an actual win32 semaphore. Obviously there's a trade-off, and I have an agenda, but would it be reasonable to deviate from POSIX lifetime on semaphores just like what was done for shared memory? Of course, this could break existing code, but if I'm not mistaken, a similar change was made in 1.48 for shared memory.
Yes, existing code was sadly broken, but lifetime semantics remained under POSIX rules (POSIX allows preserving shared memory between reboots, as shm might be implemented as mapped files). I hope to fix COM issues to get again kernel persistence, but I'll need some help from experienced windows programmers. In 1.49 beta there is some native-windows implementations of mutex, condition, etc., but those are disabled (search for BOOST_INTERPROCESS_USE_WINDOWS) until I test them a bit and I choose a absolutely-ABI-breaking release. Named semaphores are not yet implemented using winapi calls and should be implemented in that absolutely-ABI-breaking release . The idea would be: -> Create a temporary file representing the semaphore. That file stores a count when the last process attached to the semaphore is detached. -> Use file id with a "prefix bips." as global semaphore name in the system: "Global\prefix bips.XXXXXXXXXXXXXXXXXXX" -> Create on demand (open or create) a windows named semaphore with all access permissions (permissions are checked on the file). If semaphore was created, use file count as initial value. -> Write sem status to file at semaphore close. Use native file locking to serialize access to the file. This strategy is used by cygwin 1.7. This has a weak point if the last process attached to a semaphore dies, as the semaphore count won't be correctly written to the file (and the windows semaphore will dissapear. If another process opens the semaphore, the semaphore count won't be correct. If anyone discovers a more robust strategy, let me know ;-) Ion