Subject: Re: [boost] [Interprocess::Semaphore] Deadlock on more producers - one consumer problem
From: James Mansion (james_at_[hidden])
Date: 2009-06-23 16:15:29
Ion Gaztañaga wrote:
> 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?
To be honest I think the answer is 'neither' and I would like to see any
emulation of posix APIs removed too. I think its the wrong approach -
its too low level. You can get apparent flexibility by doing so but I
think its a mistake.
I think its better to look at use-cases for actual applications and look
at what's needed to support application design patterns. The key
question really is whether you expect to support sharing between
unrelated processes and why.
There seem to me to be two major use cases:
- unrelated processes that open a shared resource - the canonical
example being some sort of ISAM database perhaps
- related processes sharing a lot of state - say a web server with
shared caches and scoreboards, or databases such as Postgres with shared
memory for caches, locks and status message queues
The second of these is A LOT easier to get right because there is
typically a master process that can own the resources and ensure that
the workers only attach once the state is defined, and provide a
lifetime service. Windows and POSIX are very different in lifetime
management and also in terms of how named shared resources like
semaphores and mutexes are initialised - its hard to avoid a race with
initialisation of POSIX system scope shared resources without using some
other sort of master lock.
Personally, I would welcome a framework that helps create multiprocess
worker apps (strcuture a bit like Postgres I guess) and do it well.
That's a much higher-level problem than any attempt to force an alien
API on a system, and as such its easier to get acceptable performance
everywhere. Personally I value Windows performance as much as anything
alse and don't care for low-level emulations. ASIO is an example of
something done right, IMO.
I have some code that addresses some of these areas, but its rather
unsuitable for Boost, either through style (I'm much happier with Poco
from a style perspective) or overlap.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk