220 21855 <03e98dd3-a02e-41a6-af55-f4bdff0e4326@isocpp.org> article Path: news.gmane.org!not-for-mail From: Gor Nishanov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: is await an extension of the do-notation? (was Re: Re: Resumable expressions p0114r0 vs async/await P0057R0) Date: Sat, 17 Oct 2015 12:29:51 -0700 (PDT) Lines: 184 Approved: news@gmane.org Message-ID: <03e98dd3-a02e-41a6-af55-f4bdff0e4326@isocpp.org> References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <56114953.4030701@wanadoo.fr> <561B403D.4030403@gmail.com> <561C07D1.3080304@gmail.com> <561C213F.1060009@gmail.com> <561C3875.2050701@gmail.com> <86924069-44d0-447f-bf8a-a42e46579832@isocpp.org> <561D79A7.8080007@gmail.com> <894616d6-9609-4038-b2bc-d2c62df21e0f@isocpp.org> <99bdb3ae-9214-4440-8572-4c47a61eda46@isocpp.org> <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> <561DC957.8080603@gmail.com> <510ce172-976a-4e3a-ae68-31fdb40af4d7@isocpp.org> <9dd3f28c-4ffb-4e08-9955-242c46e14527@isocpp.org> <31d5f64f-8db9-4ba3-aca7-872114b9776d@isocpp.org> <561DE488.3040103@gmail.com> <5587a3fd-499c-42b3-bf05-fd5cdc2d9118@isocpp.org> <561EF19E.6010405@gmail.com> <7560dfa8-c77f-41ec-9c0d-c88fe65e20b5@isocpp.org> <9589b701-3237-4686-b11e-dc669e76f488@isocpp.org> <9695320b-3b02-483c-a050-5c6cad44bb1a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_903_1617720059.1445110191276" X-Trace: ger.gmane.org 1445110210 19927 80.91.229.3 (17 Oct 2015 19:30:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 19:30:10 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC47RF4IW4GRBMGDRKYQKGQENRKIAKY@isocpp.org Sat Oct 17 21:29:55 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZnXAw-00018T-QA for gclcip-std-proposals@m.gmane.org; Sat, 17 Oct 2015 21:29:55 +0200 Original-Received: by padcn9 with SMTP id cn9sf6554538pad.0 for ; Sat, 17 Oct 2015 12:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=whlS2lMinoY444tWozi+9wNt3qE7IIff23LwEmIcWhs=; b=eCJCCH5zi+See/LPL2ciXaifzpxXpdNg7a83TDZOExCsR/B9fC/PYruwEyINDVoVgR Yh9fnGNXzk5lxEki945Ol0jTsD/ee6tnL9pUDmBvX3ePcsKjksaftswBxL6F9VGprIG4 jrSP7CIvpf31KIVLz8cdpV2/IK4t0MWUOKrZmo2PDY7thdylUmETuhh5ZzDBHaiLfNE/ leCusMO9lw4veANaT4VbJK0dkKoUTDf8Ftx3IZkFvkN1HYCPC0yW0dcYtajpa2XAegNw EDs5wjbpS77u+xhROZkk709V4iAds9pCGl8D1upbyN8QdrqulBUUMk/cq2kY9Pfxu8Ci XbGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=whlS2lMinoY444tWozi+9wNt3qE7IIff23LwEmIcWhs=; b=AAieApLo757mKwlZgd7Y/nsNKE4FmQKEPf7JlIc5QdVyPcLVed7AbOXg9kJ4nAr4j4 N+JFkJ/9ypTj3ybL5cmhX2lewD9g8bKdGD8XkwVkiSkT8xpvUUpcX9aFrfBEe7uiH6AA jX1BVChhGtG43KiqZfx1zfc5rv1K15p3VzQf95aOXEFFV8Ddz457HzJl9wj/RvqhBHcw UK4q24Aclz5D3CDUP8PchcXXXFNJCuQ2pfWpeIeTYNGzFe6vkPj77MLWA26rH96lLdhV wl9uxBLgBfe1FVvXvPqnu8Ijq+HEjOhLJ9J3DiSpKAzPm97qprKqmD6BzIUAyszOghB4 BrRA== X-Gm-Message-State: ALoCoQl0sW2FCParIYf3kB51QFcPHhXgJ5W2ACN8A1bw97GaCc0/Vnf5w/r3qCXXejYGu5fXhpxv X-Received: by 10.68.94.1 with SMTP id cy1mr18609198pbb.14.1445110193074; Sat, 17 Oct 2015 12:29:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.133.90 with SMTP id h87ls462344iod.11.gmail; Sat, 17 Oct 2015 12:29:52 -0700 (PDT) X-Received: by 10.50.225.70 with SMTP id ri6mr242390igc.9.1445110192263; Sat, 17 Oct 2015 12:29:52 -0700 (PDT) In-Reply-To: <9695320b-3b02-483c-a050-5c6cad44bb1a@isocpp.org> X-Original-Sender: GorNishanov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21855 Archived-At: ------=_Part_903_1617720059.1445110191276 Content-Type: multipart/alternative; boundary="----=_Part_904_187180316.1445110191283" ------=_Part_904_187180316.1445110191283 Content-Type: text/plain; charset=UTF-8 Hi Nicol: On Saturday, October 17, 2015 at 12:08:39 PM UTC-7, Nicol Bolas wrote: The problem is that the kludge doesn't work. Or at least, it doesn't work > the same way. We discussed this earlier. > That was probably my fault in not explaining it more clearly. > In P0114, the entire call stack is taken as a single coroutine. So when > you resume the coroutine, the resume will *always* take you to the exact > cite of the `break resumable` call that suspended it. > "entire call stack" here is an illusion. The same illusion that kludge is doing. What effectively happens in P0114 is that all state machines are inlined into each other. You don't have a stack. You have a single "resumable" function that does entire thing. Similar things happen in P0057 (whether with explicit or implicit awaits). Since in this particular case coroutine lifetime does not escape the full expression it is used in the same heap elision rules apply as for generator case. In a generator case: void f(){ auto g = gen(); ... bla } // generator is destroyed, hence we can use automatic storage of f for the generator In the well-behaved sub-coroutine case (RAII semantics, destructor calls coroutine_handle::destroy()) well_behaved_future h() { await async_io(); } well_behaved_future g() { await h(); // life time starts and ends here, alloc elision applies here } well_behaved_future f() { await g(); // life time starts and ends here, alloc elision applies here }; Just like with P0114, it is only possible in non-recursive scenarios where things get inlined into each other. -- --- 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 email 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-proposals/. ------=_Part_904_187180316.1445110191283 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Nicol:

On Saturday, October 17, 2015 at 12:08= :39 PM UTC-7, Nicol Bolas wrote:


The problem is that the kludge doesn't work. Or a= t least, it doesn't work the same way. We discussed this earlier.

That was probably my fault=C2=A0in not= =C2=A0explaining it more=C2=A0clearly.=C2=A0


In P0114, the entire call stack is = taken as a single coroutine. So when you resume the coroutine, the resume w= ill always take you to the exact cite of the `break resumable` call = that suspended it.

"entire c= all stack" here is an illusion. The same illusion that kludge is doing= .. What effectively happens in P0114 is that all state machines are inlined = into each other. You don't have a stack. You have a single "resuma= ble" function that does entire thing.

Similar= things happen in P0057 (whether with explicit or implicit awaits). Since i= n this particular case coroutine lifetime does not escape the full expressi= on it is used in the same heap elision rules apply as for generator case.

In a generator case:

=
void f(){
=C2=A0 =C2= =A0auto g =3D gen();
=C2=A0 =C2=A0 ... bla
} // generator is destroyed,= hence we can use automatic storage of f for the generator

In the well-behaved sub-coroutine case (RAII= semantics, destructor calls coroutine_handle::destroy())

well_behaved_= future<void> h() {
=C2=A0 await async_io();<= /span>
}
well_behaved_future<void> g() {
= =C2=A0 await h(); // life time starts and ends here, alloc elisio= n applies here
}
well_behaved_future<void> f() {
=C2=A0 await= g(); // life time starts and ends here, alloc elision applies here<= span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">
};
=

Just like with P0114, it is only possibl= e in non-recursive scenarios where things get inlined into each other.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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-proposals/<= /a>.
------=_Part_904_187180316.1445110191283-- ------=_Part_903_1617720059.1445110191276-- .