On 10.04.2015, at 19:49, Nick Hill <[email protected]> wrote: > Accessing the CAS from multiple threads is not something that anyone would > need to do if they did not want/need to! In fact, the fact that pooling CASes > is no longer needed should make things generally much simpler for users. I.e. > not having to worry about when to release a CAS or accessing/corrupting a CAS > which had previously been 'released'. > Additionally, users can get themselves into much more trouble with the CAS > heaps and LL API, so that reasoning would also support deprecation/removal of > those?
For the record, what multi-threading scenarios are we talking about? Concurrent reading or concurrent modifications? If concurrent modifications, what kind of concurrent modifications should be supported (e.g. adding, deletion, changing existing feature values)? >> Form 4 & 6 compressed binary CAS serialization saves about 10x space over >> zip-compressed XmiCAS format. Serialization time is also 2-3x faster. >> Reducing per/experiment storage requirements from 100's of GB to 10's of GB >> was essential for much of our work. The fact that form 6, like XmiCas, >> supports deserialization into a CAS with a different but "compatible" type >> system was also essential. > > I'm not questioning the need for time/space efficient serialization or the > typesystem compatibility and FS-id-preservation requirements. I'm sure these > could be addressed without too much effort with the object-based impl. I also > think it's important that the existing formats can still be used, but I don't > think these two things necessarily need to be satisfied jointly? Currently we have a reasonably fast binary serialization that supports FS-id-preservation (CasCompleteSerializer). It would be good to continue having such a thing. I don't know if any of the other binary serializations also provides the FS-ids. Currently FS-id-preservation and lenient-loading are not supported at the same time. So no problem if those two features are not supported simultaneously. Cheers, -- Richard
