<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 2, 2015 at 8:20 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh, and speaking of the API, I don't actually understand why C++11 separates producer side (std::promise) and consumer side (std::future). My implementation is not compatible with that at all -- I just defined std::future and use that for both, just like future in java.util.concurrent. Seems working fine -- so I didn't go so far as to define one more class.</blockquote></div><br>The reason why the C++ APIs are in different classes is to make the interfaces harder to use incorrectly.</div><div class="gmail_extra"><br></div><div class="gmail_extra">By giving the producer thread only the interface which it is allowed to use, and the consumer thread only the interface which it is allowed to use, using the wrong interface or doing something that would otherwise hit an assert or cause a race condition now is a compile-time error.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It certainly adds a layer of complexity to the entire thing, but the belief was that it would significantly improve the usability of the API, and I think I largely agree with that.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If producers are always modeled as closures (the way they generally are in Java) then this isn't such a big deal as there essentially is no producer API to speak of, and you can just deal in the future side of the API.</div></div>