A race condition in the C++ runtime is a *very serious* bug.
Yeah, seriously. I wasn't aware that exception_ptr was buggy.
If I had to take a guess, I'd say it's throw and rethrow semantics during a deep nesting of try...catch's during which multiple catch handlers are in flight. I did, at the time, try setting a flag in the catch handler to invoke handling outside the try...catch which did work correctly, but broke my code where I do a particularly evil trick of using throw; as a form of return; but which invokes the next upper most try...catch handler with the currently handled exception. I could have added a TLS for the "current" exception and worked around it that way, but I figured do the Boost port first and figure it out after. Before someone suggests it's bad design, I agree it isn't pretty, but I can't think of a better way to provide exception safety for any arbitrary completion handler whilst still providing exception state propagation which is one of the key design tenets of Boost.AFIO (if an asynchronous file i/o op errors, you really, really want that error to propagate in some instances to dependent operations otherwise your usage logic becomes hideously complex to get right i.e. user code becomes very likely to be buggy). I think it's better to encapsulate the tricky, likely to be buggy code in the library rather than pushing it onto the user to get right.
[Niall Douglas]
I didn't report it yet because (a) Nov 2012 CTP isn't production
Argh. The Nov 2012 CTP contained no library changes, so this is almost certainly broken in 2012 RTM (+Update N). In fact, it's probably been broken since 2010 RTM when exception_ptr was first implemented.
Now it's probably too late to fix this in 2013 RTM. Please please please don't sit on bug reports!
I appreciate that. However, the code is not even of beta quality itself yet. It was originally pure C++11 and therefore taxes C++11 implementation in novel ways. Once it is fully converted to Boost and is mature enough that I think it reliable enough for me to draw conclusions from it about other people's code, then and only then is the right time to start formulating bug demonstration examples for third party code. You must appreciate that the proposed library is very heavily multithreaded and clang's ThreadSanitiser reports multiple possible race conditions, none of which I have touched yet as there is no point until after the Boost conversion. In other words, I don't trust my code yet.
You may have noticed a heated discussion on this very mailing list regarding the topic of Boost's long term support for compilers such as Visual Studio only recently.
I have the luxury of targeting a single compiler version. Although Boost targets multiple compiler versions, I'd recommend a policy of supporting the current and previous major versions only (excluding pre-RTM major versions). People using old compilers can use old Boosts.
As VS2010 is the last VS which will run on Windows XP, we've decided that we will target VS2010 as our absolute minimum. That will give us support of the last three major Visual Studio releases which hopefully will satisfy Boost's portability requirement, even though C++03 compatibility is gone. Additionally it greatly helps setting up the cloud per-commit unit test slaves if we can use Windows XP. Windows 7 is RAM hungry, Windows 8 is too expensive for a unit test slave, and I have an old spare licence for Windows XP. Seeing as all this test infrastructure is being funded by my personal pocket, these matters are important. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.