Re: [boost] Patch bonanza for VS2013 Preview support

Subject: Re: [boost] Patch bonanza for VS2013 Preview support
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-07-04 11:50:39

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