El 29/10/2011 12:42, Dan Brown escribió:
I'm open to that possibility but I'm still not convinced that this solution is as fundamentally off the mark as you seem to be suggesting. I will try to provide a new patch soon that addresses at least some of the issues you've raised to support that position. In my mind this also re-raises the question of whether strictly intraprocess synchronization objects could be useful, since these are, if not more common than strictly inter-process sync objects, at least very commonly used on Windows and I believe other platforms as well (ACE provides these for example). This is, in fact, precisely what I was hoping to use interprocess for in my own cross-platform project. But perhaps a library called "interprocess" is not the right home for these?
Interprocess tries to be portable and that means choosing a model for lifetime, etc. The chosen model is POSIX. Windows has essentially *named* process synchronization mechanisms, but their lifetime semantics are radically different than POSIX ones, and that's a problem (although solvable, as I think cygwin manages this). Several emulation layers need services, daemons, etc, a model Interprocess and Boost don't follow. ACE does not support mutexes placed in shared memory (_POSIX_THREAD_PROCESS_SHARED). Cygwin does not support it. APR does not support it. I've reviewed several libraries to find a better solution than current spinlock-based code, but still have not found a good solution. I'm not saying that it does not exists, I'm just saying that it is not as simple as it might seem. Interprocess has a solution, not very efficient but portable. Ion