220 21927 article Path: news.gmane.org!not-for-mail From: Oliver Kowalke 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: Wed, 21 Oct 2015 19:35:48 +0200 Lines: 187 Approved: news@gmane.org Message-ID: References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@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> <2e09660f-d688-474a-8811-85fb041f68b8@isocpp.org> <8b78abb4-16b6-4b65-8513-6e2c17317647@isocpp.org> <779be861-3b2a-427a-b36b-ad2874c81129@isocpp.org> <767364f8-785d-4f8f-9bc0-852df56ee4eb@isocpp.org> <0a728eee-e8e7-48ea-adf6-2a8dae63916e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33c6a642e3b00522a0d078 X-Trace: ger.gmane.org 1445449003 8938 80.91.229.3 (21 Oct 2015 17:36:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Oct 2015 17:36:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCLZHP5J7MHRBCE2T6YQKGQELMXT2KI@isocpp.org Wed Oct 21 19:36:25 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZoxJ3-000615-SN for gclcip-std-proposals@m.gmane.org; Wed, 21 Oct 2015 19:36:10 +0200 Original-Received: by qkck6 with SMTP id k6sf84920130qkc.1 for ; Wed, 21 Oct 2015 10:36:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=2FjCo7Aq7KAYdnPV+mqS8DGWREFyKRot0FQXMicSM/A=; b=YLs5KeqcsSDKZPfyG0Ga9vmLCCeKz0JWOilMN7uquGLlA2qj+JG1cXSIgDG6FrgBDJ g3i9TZLLrWv/GLybW0kGNh7otawXf68ZmutqUcaBM+Jm/3Hk9dbamqOVy3xgW2NLzSgP N4WVzeMSlaHwG7FONl9eklblUH9QPz+hniFwhrjOD09YSSKrvJwLiLz1let/HFj61sPs 5tFaNatvuDlLGtH+0TjDhpYrPLrFFyIUUDK+HxCvTImrzySuwzOTrO6zn4hn+Ciw2g4z cSAwpT3mn0e3V7Aq2DU+wbIeqqRKEPmBKLHCUlseYUBjrGOzJWJC2oJaTwhB9eJtHxN0 CCGA== X-Gm-Message-State: ALoCoQmnw9caB7U5Lhb3x7lsStAPw8Y3CLhlYLSUg/huDoKsA42Sba/EWDouZchymgt5j0jfi+F8 X-Received: by 10.13.236.135 with SMTP id v129mr9550171ywe.9.1445448968970; Wed, 21 Oct 2015 10:36:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.196.102 with SMTP id il6ls462629obc.17.gmail; Wed, 21 Oct 2015 10:36:08 -0700 (PDT) X-Received: by 10.60.67.1 with SMTP id j1mr7525758oet.61.1445448968067; Wed, 21 Oct 2015 10:36:08 -0700 (PDT) Original-Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com. [2607:f8b0:4003:c01::22f]) by mx.google.com with ESMTPS id cw3si6113565oec.8.2015.10.21.10.36.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 10:36:08 -0700 (PDT) Received-SPF: pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:4003:c01::22f as permitted sender) client-ip=2607:f8b0:4003:c01::22f; Original-Received: by obbda8 with SMTP id da8so46840771obb.1 for ; Wed, 21 Oct 2015 10:36:08 -0700 (PDT) X-Received: by 10.60.125.131 with SMTP id mq3mr6978657oeb.8.1445448967707; Wed, 21 Oct 2015 10:36:07 -0700 (PDT) Original-Received: by 10.76.71.233 with HTTP; Wed, 21 Oct 2015 10:35:48 -0700 (PDT) In-Reply-To: X-Original-Sender: oliver.kowalke@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:4003:c01::22f as permitted sender) smtp.mailfrom=oliver.kowalke@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:21927 Archived-At: --047d7b33c6a642e3b00522a0d078 Content-Type: text/plain; charset=UTF-8 2015-10-21 19:15 GMT+02:00 Giovanni Piero Deretta : > On Wednesday, October 21, 2015 at 5:45:22 PM UTC+1, Oliver Kowalke wrote: >> >> 2015-10-21 15:43 GMT+02:00 Giovanni Piero Deretta : >> >>> >>> Sorry for being dense, this I do not understand. I do not see how one >>> follows from the other and it doesn't match my experience. >>> >> >> for a context switch you need the current context, which is required to >> be preserved, and a target context, which has to be resumed >> I thought it is convenient only to know the target context and simply >> call execution-context::operator() to switch to the target-context. >> > > it is very convenient, but it doesn't need to save the current context > boost.context contains examples demonstrating why I introduced execution_context::current() main() -- jump to --> ctx1 -- jump to --> main() void foo( execution_context * mctx) { ( * mctx)(); } int main () { execution_context mctx = execution_context::current(); execution_context ctx1 = execution_context( foo); ctx1( & mctx); execution_context ctx2 = execution_context( bar); ctx2( & mctx); return 0; } the body of main might occur at any function/at arbitrary call chain > >> >> it is a small API - one function to resume the context, one function to >> access the current context >> >> >>> callcc is the task switching primitive: it suspend the current thread >>> of execution and resumes the target one. On the just awakened thread of >>> execution it returns the just suspened continuation. >>> >> >> it is not so much different than execution_context of course I could pass >> the current context through the context switch >> (execution_context::operator()) to the target context. >> with your callcc the target context always knows its calling context >> (parent context, what would be the right wording?). >> but in some cases the target context does not need to know from which >> context it was resumed. >> maybe callcc and execution_context are equivalent >> > > With parameter passing they are have equivalent expressibility. It is > trivial to implement callcc on top of, for example fcontext + parameter > passing: > > Assuming this exists: > void* fcontext_swap (void* p, ctxt*src, ctx*dest); > > callcc is equivalent to this: > > ctx * callcc(ctx* dst, auto f = [](auto x) {} return x; }) > { > struct data { ctx src; function f } data = { {}, > std::ref(f) }; > auto * otherdata = (data*)fcontext_swap(&data, &data.src, &dst)); > return otherdata->f(&otherdata->src)); > } > > Although it is not a terribly efficient implementation. Note that the > state of the context that we are swapping from is saved in a variable local > to callcc, no need for a global. If the target context doesn't care about > the src context, the src context can capture and store its own continuation > by providing 'f' on swap. Again, no need for a global. > do you have an suggestion how the API should changed -- --- 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/. --047d7b33c6a642e3b00522a0d078 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -10-21 19:15 GMT+02:00 Giovanni Piero Deretta <gpderetta@gmail.com&g= t;:
On Wednesda= y, October 21, 2015 at 5:45:22 PM UTC+1, Oliver Kowalke wrote:
2015-10-21 15:43 GMT+02:00 Giovanni Piero Der= etta <gpde...@gmail.com>:
Sorry for being dense, this I do not understand. I do not see how one= follows from the other and it doesn't match my experience.

for a context switch you need the current co= ntext, which is required to be preserved, and a target context, which has t= o be resumed
I thought it is convenient only to know the targ= et context and simply call execution-context::operator() to switch to the t= arget-context.

it i= s very convenient, but it doesn't need to save the current context
=

boost.context contains examples demo= nstrating why I introduced execution_context::current()

m= ain() -- jump to --> ctx1 -- jump to --> main()
=C2=A0<= br>
void foo( execution_context * mctx) {
=C2=A0 ( = * mctx)();
}

int main () {
=C2=A0 execution_context mctx =3D execution_context::current();=C2=A0 execution_context ctx1 =3D execution_context( foo);
= =C2=A0 ctx1( & mctx);
=C2=A0 execution_context ctx2 =3D execution_co= ntext( bar);
=C2=A0 ctx2( & mctx);
=C2=A0 return 0;
}
the body of main might occur at any function/at arbitrary = call chain

=C2=A0
<= br>
it is a small API - one function to resume the context, one f= unction to access the current context
=C2=A0
=C2=A0callcc is the task switch= ing primitive: it suspend the current thread of execution and resumes the t= arget one. On the just awakened thread of execution it returns the just sus= pened continuation.
=C2=A0
it is not = so much different than execution_context of course I could pass the current= context through the context switch (execution_context::operator()) to the = target context.
with your callcc the target context always kn= ows its calling context (parent context, what would be the right wording?).=
but in some cases the target context does not need to know f= rom which context it was resumed.
maybe callcc and execution_= context are equivalent

With par= ameter passing they are have equivalent expressibility. It is trivial to im= plement callcc on top of, for example fcontext + parameter passing:

= Assuming this exists:
void* fcontext_swap (void* p, ctxt*src, ctx*dest);=

callcc is equivalent to this:

ctx * callcc(ctx* dst, auto f = =3D [](auto x) {} return x; })
{
=C2=A0=C2=A0=C2=A0=C2=A0 struct data= { ctx src; function<ctx*(ctx*)> f } data =3D { {}, std::ref(f) };=C2=A0=C2=A0=C2=A0=C2=A0 auto * otherdata =3D (data*)fcontext_swap(&da= ta, &data.src, &dst));
=C2=A0=C2=A0 =C2=A0 return otherdata->= f(&otherdata->src));
}
=C2=A0=C2=A0=C2=A0=C2=A0
Although i= t is not a terribly efficient implementation. Note that the state of the co= ntext that we are swapping from is saved in a variable local to callcc, no = need for a global. If the target context doesn't care about the src con= text, the src context can capture and store its own continuation by providi= ng 'f' on swap. Again, no need for a global.
=
do you have an suggestion how th= e API should changed

--

---
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>.
--047d7b33c6a642e3b00522a0d078-- .