Subject: Re: [boost] [compond_file_binary] Gauging interest in a possible library submission.
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2012-12-05 09:46:12
> First of all I want to mention that my library is not finished yet. I am
> at the end of implementing planned features for the first release, but
> some additional effort is needed. I have no plans to add support for the
> all features that MS implementation provides in the first release, but
> want to develop library in evolutionary way. Also I plan add some features
> in next releases that are not supported by MS implementation: storage
> compacting and defragmentation. I found on the Internet that users need
> > More generally, does your library support the properties of the MS
> > compound storage implementation as described here:
> > http://msdn.microsoft.com/en-
> > ?
> Here is that list with my comments.
> [Incremental access.]
> Implemented and tested.
> [Multiple use.]
> Not implemented, but I think often about that. The main problem: I can not
> decide use C++11 threading model or switch to some cross-platform
> library(Boost.Thread may be?)
> For now supported one thread per one compound files.
> Also, threading implementation and testing will require lot of effort. And
> not plan to include multithreading support in the first release.
I don't think the library has to care about what type of threading model is
used. I imagine the problem of making the files accessible concurrently is
even wider as you have to enable multiple processes to read/write
concurrently. The MS implementation achieves this using the transactional
mechanisms, which moves the responsibility for making it concurrency safe
into user land. Essentially every write creates a new subtree (stream),
which then is made current by a single atomic write operation, invalidating
the previous version of the data.
> [Transaction processing.]
> Not supported. Planned in next releases.
Good, that's one of the main advantages of this model, in my book.
> [Low-memory saves.]
> Yes. I designed the library to be memory efficient. All needed memory is
> allocated on stream opening.
> I plan to test memory issues by emulating std::bad_alloc in various
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk