220 21926 article Path: news.gmane.org!not-for-mail From: Giovanni Piero Deretta 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 10:15:57 -0700 (PDT) Lines: 150 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/mixed; boundary="----=_Part_4609_210998052.1445447757761" X-Trace: ger.gmane.org 1445447775 20705 80.91.229.3 (21 Oct 2015 17:16:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Oct 2015 17:16:15 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDEP3I7TGEIM5EE7WECRUBEHAPPAC@isocpp.org Wed Oct 21 19:16:11 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zowzd-0001rE-JW for gclcip-std-proposals@m.gmane.org; Wed, 21 Oct 2015 19:16:05 +0200 Original-Received: by vkfw189 with SMTP id w189sf81034368vkf.1 for ; Wed, 21 Oct 2015 10:15:59 -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=3Q3g1NTBTUzNqD1WLJFbUD5gz/OyxzRgMoAJixyt2wo=; b=qjQvtEsrD5Fkw8i2t0AKUlSnexopeYIyU0HOJqzUcn972rvDDWtJJPMyUEHYVlj8gk 7SH5LviVgGaDEZNz2Jl5q0kFrCDO6iD8185hYXtWyQquLSEuBmcpY4nbJBKFJtNSHfGO d9KBpk+jZ2TU2af1+Dq/4vIscZ3UR4kX90VhLbsGaHEhg6QUriqg/7Yt9Hkc5sZRavGZ qZTnjfwA0jGbqOSGGnkXRBpvo8wVmHmJyQj+cRZLwdkMhiBKARapYLj/8e2jzfwqIEsE IG7ssQd7LKWloE9r5spuGbrsmTvjXXWWshalay4is2S8bxPyROxXRZbO49xDf5ARdhlD 9CuQ== 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=3Q3g1NTBTUzNqD1WLJFbUD5gz/OyxzRgMoAJixyt2wo=; b=g4uus5edMXPGhKnDq/yBpkVyb2Cti5CCda9qCGz1+SSbYQb+jvTf8RRxPBBxcqnB9Q Waxsp+jdvC1qfXj5DXUB3Jvm6+hrGBNEr0WwYJ4ivAODgSfF5GcnmBg7v8Oa29AKZrYW Nq8LTtrU5FMRfsL9t73f8Z+oQgcg0xr34EeSSLYFaH+4Vi6xfO1TPfzRytnRuWGTUvSs eXbVfBJfd8vImGZaYipIJSeC2OEm8SOXG6Cz9ZLIFPl7i6sG5CVNAuLBMOVfsaiAvUxM 52yu7lZiq2KsYKEyojlBsu0Mml+A42JH3nAvVcmcWUwvyCSl9OXz7V6mr3t/r7Gbv/Y+ AEvA== X-Gm-Message-State: ALoCoQkhIa1noHg5LlCBoovIaZbXa0BVxeCWjbMxd/z5dcI+4KZIopvB00clhoafc43WmMOZsgpk X-Received: by 10.129.78.205 with SMTP id c196mr8532817ywb.21.1445447759698; Wed, 21 Oct 2015 10:15:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.78.202 with SMTP id d10ls1583837igx.41.canary; Wed, 21 Oct 2015 10:15:58 -0700 (PDT) X-Received: by 10.50.122.103 with SMTP id lr7mr272558igb.10.1445447758834; Wed, 21 Oct 2015 10:15:58 -0700 (PDT) In-Reply-To: X-Original-Sender: gpderetta@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:21926 Archived-At: ------=_Part_4609_210998052.1445447757761 Content-Type: multipart/alternative; boundary="----=_Part_4610_1038812166.1445447757761" ------=_Part_4610_1038812166.1445447757761 Content-Type: text/plain; charset=UTF-8 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 > > 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. -- --- 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_4610_1038812166.1445447757761 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 <gpde...@gmail.com>:

it is a small= API - one function to resume the context, one function to access the curre= nt context
=C2=A0
= =C2=A0callcc is the task switching primitive: it suspend the current thread= of execution and resumes the target one. On the just awakened thread of ex= ecution it returns the just suspened continuation.
=C2=A0
it is not so much different than execution_context of = course I could pass the current context through the context switch (executi= on_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 ta= rget context does not need to know from which context it was resumed.
maybe callcc and execution_context are equivalent
<= /blockquote>

With parameter passing they are have equivalent expres= sibility. 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:

c= tx * 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 } da= ta =3D { {}, std::ref(f) };
=C2=A0=C2=A0=C2=A0=C2=A0 auto * otherdata = =3D (data*)fcontext_swap(&data, &data.src, &dst));
=C2=A0=C2= =A0 =C2=A0 return otherdata->f(&otherdata->src));
}
=C2=A0= =C2=A0=C2=A0=C2=A0
Although it is not a terribly efficient implementati= on. Note that the state of the context that we are swapping from is saved i= n a variable local to callcc, no need for a global. If the target context d= oesn't care about the src context, the src context can capture and stor= e its own continuation by providing 'f' on swap. Again, no need for= a global.


--

---
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_4610_1038812166.1445447757761-- ------=_Part_4609_210998052.1445447757761-- .