Re: [boost] [Interprocess::Semaphore] Deadlock on more producers - one consumer problem

Subject: Re: [boost] [Interprocess::Semaphore] Deadlock on more producers - one consumer problem
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-06-22 16:01:33

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