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