220 21596 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0099 suggestion: Minimal support for asymmetric suspend/resume Date: Mon, 12 Oct 2015 09:32:39 -0700 (PDT) Lines: 178 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_617_873234289.1444667559848" X-Trace: ger.gmane.org 1444667568 2948 80.91.229.3 (12 Oct 2015 16:32:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 16:32:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBKOB56YAKGQEU7A4GNI@isocpp.org Mon Oct 12 18:32:47 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zlg1i-0008Ft-Pk for gclcip-std-proposals@m.gmane.org; Mon, 12 Oct 2015 18:32:42 +0200 Original-Received: by pacru14 with SMTP id ru14sf75298726pac.0 for ; Mon, 12 Oct 2015 09:32:42 -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=gMRmHh2XlTUh5NEpDu3FkSPg7xGfzXzFtv8IIiV3100=; b=kqo+qB/+D41tICFAiwRrH6ln4OVrE7WqBUX+biXWOwMz2D0A+JlmbaUxqDHyQsNlge fIS8qR07Qu1g41BRyVj5sdu4RZsHPDGxqNCLRLi1Ij0p3nky9A/Zd0Ka5g6k/0ODROdz d5Nd9yNIVb2Ih9/tnQVxUAkpjWK/8c2mBYD48I+ces8rMULefNfpoSeSad7wbBNbAEFg Ao2ocVwvI3Iftkj2uqmahzx7Xl471f7O/sstw5sotSwT0h6fLJeR/Yh8IWsp52R4L+NU 7hDDb2YBfEuyAqXeSV7R37L5LN097XtcL47XyTYR4CUI363TCc9i0Dqh0WJV/u5hWuqT EpIA== 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=gMRmHh2XlTUh5NEpDu3FkSPg7xGfzXzFtv8IIiV3100=; b=Ji/ukexB866HkIHxBINAMZbny3xo86xFn4lkf++5OcZoF8ndhwcqxqGzkd8txnkJCe vpPWtvRY2W4kDxL8yST7szXy4HbhJJ8XFZq4pchh4KaCzJNTaJWJZSEO1Wh3d8eCPQ1d qDjpHqrOp2dVhb7pQaqRtP3ZJXuqi3DmF2W+GsQBkljvF4/bqALZXj2FbYdlQT0ynSVg ZhvQFOej80dSa72c9cnhFix9kNF4T1tNRNbjcTQn3FF7B66IxCsmx3JhabcrkWAvLyk8 jK2Y5WNIytB0MRCdLj5VCdwEs1pi6K+uzD/e93atUfa8yXNXaI5UnqJ2v3BBylPYEC+d RR/g== X-Gm-Message-State: ALoCoQmiM55YuOXZfpeDEFVQdWhoL8EQqqYjI+54ymSX1V50tJKIN+nzaJdOhbazD02aQtHMu4ND X-Received: by 10.67.14.6 with SMTP id fc6mr25654512pad.14.1444667561990; Mon, 12 Oct 2015 09:32:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.61.204 with SMTP id s12ls1222795igr.25.canary; Mon, 12 Oct 2015 09:32:40 -0700 (PDT) X-Received: by 10.50.143.12 with SMTP id sa12mr142797igb.7.1444667560792; Mon, 12 Oct 2015 09:32:40 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:21596 Archived-At: ------=_Part_617_873234289.1444667559848 Content-Type: multipart/alternative; boundary="----=_Part_618_1426928661.1444667559849" ------=_Part_618_1426928661.1444667559849 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, October 12, 2015 at 1:18:34 AM UTC-4, Gor Nishanov wrote: > > Hmm... I think you can take execution_context as proposed in p0099 and=20 > build a higher level abstraction on top without losing any efficiency. > None of the options I've suggested involves any loss of efficiency (even=20 options 1 and 2 are just an extra pointer). The default case is still=20 symmetric operation; the possibilities I've outlined simply allow for the= =20 *chance* to make them asymmetric. =20 > Something like this: > > fiber ctors + swap + assignment + destructor + > > fiber.join() =E2=80=93 resumes the fiber (remembers the context who calle= d it) > > this_fiber::suspend() =E2=80=93 yields back to whomever called it > The first two are easy enough to do. It's the third part that seems=20 impossible. `execution_context::current` gives you the current=20 `execution_context`, but how do you convert that into a user-defined type?= =20 That is, how do you implement `this_fiber`, given only=20 `execution_context::current` to work with? You can't just do some kind of static_cast from an `execution_context` to a= =20 derived type, since your derived class has actual state (namely, the fiber= =20 that called it). You need a mapping table from a fiber-created=20 `execution_context`s to actual `fiber` that created it. And that requires= =20 some way to uniquely associate an `execution_context` with a `fiber`. That's what option #3 does: provide an identifier for an=20 `execution_context`, so that you can associate objects with it. I don't know of a way to do that without explicit support from=20 `execution_context`. After all, getting the address of a handle type means= =20 nothing relative to the object being referenced by the handle. Also, Boost.Coroutine2 isn't an answer. Despite its claims to the contrary,= =20 it implement symmetric coroutines. Just look at all of the examples in the= =20 documentation=20 :=20 they're not asymmetric at all. All of them are resuming a *specific*=20 coroutine. Not one of them yields execution directly to its caller without= =20 being explicitly told which coroutine it should yield to. They're=20 generating values for a specific execution context, or retrieving values=20 *from* a specific execution context. Boost.Coroutine2 is all about getting= =20 values from Boost.Context's symmetric coroutines. The point of an asymmetric coroutine is that you *don't know* who your=20 caller is. And you don't care. You could be executed from one context one= =20 time, then resumed from another context later. You don't care which it is;= =20 you just want to yield back to whomever it was that started you. Boost.Coroutine2 does not provide this. Well, not without passing a=20 specific object up the callstack to whomever yields (and quite frankly, I= =20 can do that with `execution_context`). Remember: we want stackful coroutines precisely because we want to be able= =20 to yield anywhere. So we may be very far from that lambda, and we=20 absolutely do not want to have to pass the context to yield to through=20 every single function along the way. --=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/. ------=_Part_618_1426928661.1444667559849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Monday, October 12, 2015 at 1:18:34 AM UTC-4, Gor Nisha= nov wrote:
Hmm= .... I think you can take execution_context as proposed in p0099 and build a= higher level abstraction on top without losing any efficiency.

None of the options I've suggested involves any loss of= efficiency (even options 1 and 2 are just an extra pointer). The default c= ase is still symmetric operation; the possibilities I've outlined simpl= y allow for the chance to make them asymmetric.
=C2=A0
Something lik= e this:

fiber ctors + swap = + assignment + destructor +

fiber.join() =E2=80=93 resumes the fiber (remembers = the context who called it)

this_fiber::suspend() =E2=80=93 yields back to whome= ver called it


The first two are easy e= nough to do. It's the third part that seems impossible. `execution_cont= ext::current` gives you the current `execution_context`, but how do you con= vert that into a user-defined type? That is, how do you implement `this_fib= er`, given only `execution_context::current` to work with?

You can&#= 39;t just do some kind of static_cast from an `execution_context` to a deri= ved type, since your derived class has actual state (namely, the fiber that= called it). You need a mapping table from a fiber-created `execution_conte= xt`s to actual `fiber` that created it. And that requires some way to uniqu= ely associate an `execution_context` with a `fiber`.

That's what= option #3 does: provide an identifier for an `execution_context`, so that = you can associate objects with it.

I don't know of a way to do t= hat without explicit support from `execution_context`. After all, getting t= he address of a handle type means nothing relative to the object being refe= renced by the handle.

Also, Boost.Coroutine2 isn't an answer. De= spite its claims to the contrary, it implement symmetric coroutines. Just l= ook at all of the examples in the docum= entation: they're not asymmetric at all. All of them are resuming a= specific coroutine. Not one of them yields execution directly to it= s caller without being explicitly told which coroutine it should yield to. = They're generating values for a specific execution context, or retrievi= ng values from a specific execution context. Boost.Coroutine2 is all= about getting values from Boost.Context's symmetric coroutines.
The point of an asymmetric coroutine is that you don't know who= your caller is. And you don't care. You could be executed from one con= text one time, then resumed from another context later. You don't care = which it is; you just want to yield back to whomever it was that started yo= u.

Boost.Coroutine2 does not provide this. Well, not without passing= a specific object up the callstack to whomever yields (and quite frankly, = I can do that with `execution_context`).

Remember: we want stackful = coroutines precisely because we want to be able to yield anywhere. So we ma= y be very far from that lambda, and we absolutely do not want to have to pa= ss the context to yield to through every single function along the way.
=

--

---
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_618_1426928661.1444667559849-- ------=_Part_617_873234289.1444667559848-- .