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

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.

James