I think you should separate the two things. Get the required changes in and make the initial version of the library available, then work on new features.
Right. But I should state that changes in Shmem/Interprocess are quite problematic since binary compatibility is required in all the classes placed in shared memory/memory mapped files (mutex, condition, containers, allocators, rw_locks...). That means that a change in those classes (for example, adding a more efficient version of a synchronization object) will mean that the user must recompile all the processes using Shmem/Interprocess. So I would like to minimize breaking changes, so the first official Interprocess should be pretty stable.
As soon as you upload and register into the regression system you will get to see how it works on a variety of platforms (well, at least after 1.34 ships you will). Folks interested in a particular compiler/platform may start looking at it an helping you port. And beyond the formal regression tests, others of us regularly update, rebuild, and run regression tests. I don't tend to mess with anything in the sandbox unless I really, really want to use it for something (in fact we really need to clean the old stuff out). Most new Boost developers don't realize that the process of getting in CVS and the regression test system will take a couple months...
All right. I will request write access in CVS and I will start learning the regression system.
I just worry about you falling into the circular_buffer trap. A perfectly usable and accepted library that 2 years later because of some issues the author doesn't now have time to address. It's a loss to the community and a shame. I don't have an immediate need for inter-process, but there's alot of concurrency/multi-process code in progress in Boost for SOC and otherwise. Interprocess is a piece of that puzzle -- so I'd like to see more eyes and testing on it sooner rather than later. Getting it into CVS accomplishes the first step.
Agreed. Ion