Re: [boost] [compond_file_binary] Gauging interest in a possible library submission.

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
> them.

Sounds good.

> > More generally, does your library support the properties of the MS
> > compound storage implementation as described here:
> >
> >
> > http://msdn.microsoft.com/en-
> us/library/windows/desktop/aa378871(v=vs.85).aspx
> > ?
> 
> 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
> I
> 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
> places.

Thanks!

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu