Bryce Lelbach aka wash wrote:
Maybe we could come up with a few use cases for thread-safety in xml_archives?
I assume you mean tests.
I'd be happy to implement a small test suite if you could give me some parameters to work off of. Then you could verify the existing implementation and earlier versions of Serialization, and I could ensure my rewrite performs as desired in concurrent applications.
Note that there is an extensive test suite for the serialization library. You should run that on your local machine. This entails running bjam with the right switches. They way I do it is to cd to the test directory and invoke ../../../regression/tools/src/library_test.sh This will run all the tests with your new version and generate a complete table with test results. Be sure and test all combinations debug/release, static/dynamic versions. It takes some time to run, but it doesn't require any manual effort.
At this point I've ported about 90% of the grammar.
Great, as with all software projects, you've only got 90% left to go.
I've also replaced your assign/append functors (for Spirit Classic semantic actions) in /boost/archive/impl/basic_xml_grammar.ipp with Phoenix lambda expressions.
I assumed something like that would be necessary.
The Classic XML parser has a number of workarounds in the grammar for template depth issues on Darwin (GCC 3.1). These workarounds seem to be deprecated (circa 2004);
I'm not sure what it means to deprecate a work around. Maybe you mean that they aren't necessary with later versions. The workaround code should indicate which compiler version they apply to. So maybe it's just a question of changing. I would like to avoid hearing from someone who has an old compiler if I can avoid it.
Spirit Qi tends to instantiate deeper templates than Spirit Classic, and more modern versions of Darwin GCC seem capable of handling Spirit Qi. I'd appreciate it if you could let me know if I'm missing part of the picture in regards to these workarounds (they're in the ctor for the grammar, in /boost/archive/impl/basic_xml_grammar.ipp).
The way it works is that the package is released, and the problems come in. As they come in, they are addressed with the workarounds. I don't see anyway around this. If you start with a clean slate, the cycle will begin a new. So, I would leave in the workarounds if they still seem applicable. If they don't seem to fit anymore, then clean things up. It's really a matter of judgement. I'm going to leave it up to you since you'll be dealing with any complaints which arrive in the future. Thanks for taking this on. My understanding is that the new library is much faster than the currently used one so people should be happy about that. Good Luck with this. Robert Ramey