Zachary Turner wrote:
Not sure what a khazi is :) But regardless, I also feel like modelling it after posix semaphores is a bit contrary to how other libraries in boost work, or how boost libraries are supposed to work in general (correct me if I'm wrong). It seems to me like you should be starting with requirements, and molding the o/s primitives to fit the requirements. Not molding the requirements to fit specific o/s primitives.
How are Boost libraries suppossed to work? First of all, the goal of the library was portability it's easier to model POSIX primitives in Windows than the inverse without the need of any server daemon. After all, POSIX is supposed to be the standard, isn't ist?
For example, does anyone actually care that specifically that a semaphore is in shared memory or a memory mapped file? Or do they just care that it can be accessed from multiple processes? Ok fine, before you shoot me, I'm sure that some people actually do want it to be in a specific type of memory for whatever reason. But regardless, both o/s'es provide native support for semaphores that can be used from multiple processes. It seems like the interface should be designed simply to distinguish whether or not it can be used in multiple processes, and make the internals hide the rest.
There are specific uses for process-shared (in posix sense) primitives. Interprocess also offers named primitives, similar to sem_open functions, but they are also modeled after POSIX primitives. Both have their uses.
There may be situations where you really want some o/s specific behavior, but that's what an interprocess::posix namespace could be used for. Like in boost::asio I can use boost::asio::windows::overlapped_ptr
Ok, Boost libraries are supposed to be the base of standardization and that requires portability at least in UNIX and Windows. I found POSIX behaviour was more portable. If OS-specific primitives are demanded, I will add this to the to-do list and I'll try to find some time for this. If anyone that is an expert on an specific OS primitives, contributions are welcome. Best, Ion