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-23 12:02:07

James Mansion wrote:
> Its a standard.  It has the supposed advantage of being a de jure 
> standard - but what does that mean in reality?  Portability between a 
> lot of bit players?  Real world portability has to mean Windows, MacOS 
> and Linux now, with 'real POSIX' somewhat secondary, which is galling 
> for those of us with sympathy for systems like Solaris with a history of 
> POSIX compliance foremost and frippery second.

I think current approach is portable between Windows, MacOs and Linux. 
Maybe not as efficient as it should be, but portable anyway. Portable 
enough to present a shared memory proposal to the standard.

> Windows and POSIX are sadly rather different even when the APIs are 
> superficially similar.  You can fake one on the other but doing so with 
> the same atomicity is quite hard - even at the level of something as 
> ostensibly simple as pread.  There is no substitute for designing for 
> both approaches at once.  Still, its done now, unless there is any real 
> stomach to have a second attempt at a shared memory API for Boost.

I think current attempt is positive, taking in care all the difficulties 
you've just mentioned. If that's not enough, I'm open to suggestions, 
but I definitely need help, because sadly I can only dedicate a small 
part of my time to Boost. What would like to see in the library, 
additional classes for Windows IPC, and System V IPC? Since implementing 
all those is a heavy task, do you have some preferences on what should 
we implement first?

Best,

Ion