[cpp-threads] Asynchronous Function Proposal

[Beman Dawes]

On Tue, Jun 9, 2009 at 5:18 AM, Peter Dimov<pdimov at mmltd.net> wrote:
> Boehm, Hans:
> ...
>
>> I'm still unsure what the programming rules for thread_locals should be.
>> And without that, it seems to be hard to answer these questions.
>>
>> I think most people are arguing for an approach in which client code has
>> to be very careful about storing unknown data D with nontrivial destructors
>> into thread_locals, so that we can be sure that D is destroyed while it is
>> still safe to do so, just as you would with static duration variables.  In
>> that case, we might be able to allow running on another thread.
>>
>> My only problem with this is that it makes it very hard to use
>> thread_locals in generic library code, e.g. to cache the last value I looked
>> up in a map.
>
> I'll try to use an analogy to show why I have a severe problem with this
> reasoning. It took me a while to distill it, and it's not perfect. Still.
>
> I see you as saying the equivalent of:
>
> - I can easily write a type X such that std::set<X> crashes and burns.
> - I can think of no way to write std::set so that it doesn't crash and burn
> when fed X.
> - Therefore, std::set is very hard to use in generic code, because someone
> may feed X to it.
> - Therefore, std::set must be removed from the standard.
>
> The hundreds of thousands of C++ programmers that use std::set every day
> somehow don't enter the equation, and neither does their pragmatic solution
> to the problem - use it when it works, do not use it when it doesn't.

Agreed, however:

* It might be possible to reformulate the component in a way that
would avoid or minimize the pitfalls yet preserve full functionality.
That's worth exploring.

* If there is just no way to avoid the pitfalls, we should explore
adding non-normative comments warning of the danger area.

* Sometimes we say that doing X causes undefined behavior. That's
essentially a danger  warning serious enough to be made normative.

--Beman