220 4754 <51A7B271.1030903@wanadoo.fr> article
Path: news.gmane.org!not-for-mail
From: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: N3558 :A standardized representation of
 Asynchronous operation
Date: Thu, 30 May 2013 22:11:29 +0200
Lines: 68
Approved: news@gmane.org
Message-ID: <51A7B271.1030903@wanadoo.fr>
References: <519F9E48.7050700@wanadoo.fr> <51A0B7C3.40109@wanadoo.fr> <51A6EFE6.4030407@wanadoo.fr> <51A7039F.20007@gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Trace: ger.gmane.org 1369944697 7316 80.91.229.3 (30 May 2013 20:11:37 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Thu, 30 May 2013 20:11:37 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBDH67CONY4PBB57ET2GQKGQEZJMP7EQ@isocpp.org Thu May 30 22:11:36 2013
Return-path: <std-proposals+bncBDH67CONY4PBB57ET2GQKGQEZJMP7EQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-we0-f198.google.com ([74.125.82.198])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBDH67CONY4PBB57ET2GQKGQEZJMP7EQ@isocpp.org>)
	id 1Ui9CC-00080J-Cp
	for gclcip-std-proposals@m.gmane.org; Thu, 30 May 2013 22:11:36 +0200
Original-Received: by mail-we0-f198.google.com with SMTP id q56sf681738wes.5
        for <gclcip-std-proposals@m.gmane.org>; Thu, 30 May 2013 13:11:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=x-beenthere:message-id:date:from:user-agent:mime-version:to:subject
         :references:in-reply-to:x-original-sender
         :x-original-authentication-results:reply-to:precedence:mailing-list
         :list-id:x-google-group-id:list-post:list-help:list-archive
         :list-subscribe:list-unsubscribe:content-type
         :content-transfer-encoding;
        bh=FTwisBZCGQgMfmIWzvAyNWaNXktR0WAR4DUaAuE5PwA=;
        b=Yz+vxB9sPPyOmX9YJjKaCWh8g6R6RvDaWICfx9RFnsRoztgxKOJhTFa1KJ4ST48BR1
         /y/NjtrlGsBDtMR9t03ymAe5mpx6+MnMZlqxgeuRoBya2kBW3bP8gCim/G/3Z2MgnURP
         NzKO5Z8O0SCZjt/vKHTq1655caXwzWkk+ydYJFDErjB/uV7EIaBQBGC6x5reRO663bBJ
         RoIfVznhRsnz47M3oFP36lLjlO8yIz4rjEm9i5Xm6QjGCgY655S6L8OF7K4FGqF9DewF
         BbQ9Gv33qDDPtu9jxsqjKOxXWhqXuM998VdjGjgcsWcqjooE/7N6a1gqcV+ 
X-Received: by 10.180.206.107 with SMTP id ln11mr251865wic.7.1369944695915;
        Thu, 30 May 2013 13:11:35 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.180.87.106 with SMTP id w10ls39619wiz.44.canary; Thu, 30 May
 2013 13:11:34 -0700 (PDT)
X-Received: by 10.14.88.130 with SMTP id a2mr11050234eef.53.1369944694608;
        Thu, 30 May 2013 13:11:34 -0700 (PDT)
Original-Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr. [80.12.242.128])
        by mx.google.com with ESMTP id s48si19523778eel.126.2013.05.30.13.11.34
        for <std-proposals@isocpp.org>;
        Thu, 30 May 2013 13:11:34 -0700 (PDT)
Received-SPF: neutral (google.com: 80.12.242.128 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.128;
Original-Received: from pc4.home ([92.139.33.178])
	by mwinf5d63 with ME
	id iLBX1l0063qbqms03LBYDV; Thu, 30 May 2013 22:11:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
In-Reply-To: <51A7039F.20007@gmail.com>
X-Original-Sender: vicente.botet@wanadoo.fr
X-Original-Authentication-Results: mx.google.com;       spf=neutral
 (google.com: 80.12.242.128 is neither permitted nor denied by best guess
 record for domain of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.fr
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post?hl=en>,
 <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?hl=en&topic=25838>,
 <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4754
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/4754>

Le 30/05/13 09:45, Anthony Williams a =E9crit :
> On 30/05/13 07:21, Vicente J. Botet Escriba wrote:
>> Le 25/05/13 15:08, Vicente J. Botet Escriba a =E9crit :
>>> Le 24/05/13 19:07, Vicente J. Botet Escriba a =E9crit :
>>>> Hi,
>>>>
>>>> What is the rationale for when_all to return
>>>> future<vector<future<R>>> instead of  future<vector<R>>?
>>>> What is the rationale for when_any to return
>>>> future<vector<future<R>>> instead of future<pair<size_t, R>> ?
>>>>
>>>>
>>> I have one more question about when_any. What would be the expected
>>> behavior when when_any has parameters that shared the same shared
>>> state, as in
>>>
>>>     std::shared_future<int> fi1 =3D
>>> std::async(calculate_the_answer_to_life_the_universe_and_everything).sh=
are();
>>>     std::shared_future<int> fi2 =3D fi1;
>>>     std::when_any(fi1, fi2).wait();
>>>
> This will wait until the async finishes. Both futures become ready
> together, so there is no problem here.
Shouldn't the wait function synchronize with the each one of the=20
futures? I was thinking here to the implementation of=20
boost:;wait_for_any which locks all the future shared state mutex, and=20
deadlocks as the same mutex is locked twice.
>
>> Or even this radical one
>>
>>     std::future<int> fi1 =3D
>> std::async(calculate_the_answer_to_life_the_universe_and_everything).sha=
re();
>>     std::when_any(fi1, fi1).wait();
> This shouldn't compile, since fi1 is not copyable, so you should have to
> move it into the when_any call.
Of course. My bad, I was using it as boost::wait_for_any which takes the=20
futures by reference.
>
> Under the current spec, the interface allows it to compile,
I'm lost. Do you mean after moving it?

    std::when_any(move(fi1), move(fi1)).wait();

Vicente
> but it may
> fail due to internal implementation details, in which case the spec
> needs updating.
>
> If it did compile then I would expect it to complain about an invalid
> future, since after moving the first arg the second one will be empty.
>
> Anthony

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.
