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