220 21957 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: Fri, 23 Oct 2015 08:45:00 +0200 Lines: 160 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> <6a4f863e-faf0-42ac-b85d-0951738350ab@isocpp.org> <1f818f79-1fe3-4e9f-b5c7-07836547dd74@isocpp.org> <5d4d4143-dcbb-401f-b809-6d1e50840fc4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e015383e88876050522bff496 X-Trace: ger.gmane.org 1445582728 24221 80.91.229.3 (23 Oct 2015 06:45:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 06:45:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCLZHP5J7MHRBAFPU6YQKGQEKEQ3BDI@isocpp.org Fri Oct 23 08:45:23 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 1ZpW6M-0002Q6-PZ for gclcip-std-proposals@m.gmane.org; Fri, 23 Oct 2015 08:45:23 +0200 Original-Received: by pabih17 with SMTP id ih17sf44092773pab.2 for ; Thu, 22 Oct 2015 23:45:21 -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=QYhVxb6rQXbVDZ3i9udsNdXgs8b2ouYN+FD5P2S6wxY=; b=RQO98/XA2KIDb/na7d5iBDAAJcKhRph5q8cvaXO79R0lKT2syDQRY+/hjWoj/EJWVL SOQxw7nnzDUaM8qaxhCSBGjbuJVfAOcRRqcayYYWWcBdHnhoi0a7EcnVw+nJdojD/woC BYQ5DjEeIRKw0DAOS7eoS6N247EgoqGky9ERP3dGdn+oSeLoNkBefZxfKLts4WDMujiJ 63ndGYv2e0vF3DYclsXT0xQG3JFhPSccbDYhObFID8ANzTJrhVcy/lU7OUoMpuSR9gSx xNROVaqkwG8tsNbrpK4dMIJsm43/S84q26XkpMKUXb6XgMWr6fiXOdbL/RnT0gW+uIv8 S0Kg== X-Gm-Message-State: ALoCoQmT9ZZwKSveWsCh7MRXFAeTh9dL1jEj8e8ei9lbVlCcz6/UPmBSGD5b8BppEO0xMxE9A2Cw X-Received: by 10.67.7.35 with SMTP id cz3mr15739311pad.40.1445582721466; Thu, 22 Oct 2015 23:45:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.33.74 with SMTP id p10ls1151875obi.80.gmail; Thu, 22 Oct 2015 23:45:20 -0700 (PDT) X-Received: by 10.202.209.141 with SMTP id i135mr12169863oig.25.1445582720420; Thu, 22 Oct 2015 23:45:20 -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 j8si11239851oeo.51.2015.10.22.23.45.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2015 23:45:20 -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 obbwb3 with SMTP id wb3so86943712obb.0 for ; Thu, 22 Oct 2015 23:45:20 -0700 (PDT) X-Received: by 10.182.191.38 with SMTP id gv6mr13358002obc.7.1445582720233; Thu, 22 Oct 2015 23:45:20 -0700 (PDT) Original-Received: by 10.76.71.233 with HTTP; Thu, 22 Oct 2015 23:45:00 -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:21957 Archived-At: --089e015383e88876050522bff496 Content-Type: text/plain; charset=UTF-8 > > Then a synthesized context (== passed as arg to the context-fn) is not the >> same as context created with context(Fn&&,Args&&...). >> > > All contextes are the same. The point is that a context can be called only > once. If you invoke it in foo to go back to main, you can't invoke it > again. To prevent misuse operator() should clear the context. When > operator() returns, context will again point to a new context. > if a context can be called only once how do you implement generators for instance ( source/parent context not explicitly returned by context::operator()): void fibonacci( context sink, int n) { int first = 1, second = 1; sink( first); sink( second); for ( int i = 0; i < n-2; ++i) { int third = first + second; first = second; second = third; sink( third); } } context source( fibinacci, 10); for ( int i : source) { std::cout << i << std::endl; } if a context can only be called once the fibonacci example would not work. I assume that you mean that each invocation of source() (context switch) updates the fcontext_t in sink is updated. because sink can be moved down the callstack (to sub-routines) you need a pointer to fcontext_t to update the structure or you pass fcontext_t through jump_fcontext and update the structure before you return from context::operator() of instance sink. that's how boost.coroutine(2) works. but how should a absolute minimalistic API for stackful context switching look like? execution_context uses a pointer that is updated at each context switch, e.g. execution_context::operator() is implemented like: void operator()( void * vp) { ptr from( this); current.swap( from); // *this becomes current execution-context intptr_t ret = jump_fcontext( & from, this, vp); // resume *this return reinterpret_cast< void * >( ret); // return parameter transferred from *this } in contrast to context<> execution_context doesn't know its predecessor or successor. you criticize that current is a static pointer (that must be thread-local because we operate in a multi-threaded env). please note that this is a library implementation, it might be possible that a compiler can implement execution_context in a more efficient way. at least the main aim should be to design a really minimalistic API useable to build higher level abstractions. -- --- 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/. --089e015383e88876050522bff496 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Then a synthesized context (=3D=3D passed as arg to = the context-fn) is not the same as context created with context(Fn&&= ;,Args&&...).

All= contextes are the same. The point is that a context can be called=20 only once. If you invoke it in foo to go back to main, you can't invoke= =20 it again. To prevent misuse operator() should clear the context. When=20 operator() returns, context will again point to a new context.

if a context can be called only once how do y= ou implement generators for instance ( source/parent context not explicitly= returned by context::operator()):

void fibonacci( contex= t<int> sink, int n) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 int first =3D 1, second =3D 1;
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sink( first);
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sink( second);=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for = ( int i =3D 0; i < n-2; ++i) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int third =3D first = + second;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 first =3D second;
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 secon= d =3D third;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sink( third);
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
}

context= <int> source( fibinacci, 10);
for ( int i : source) {
=C2=A0=C2=A0 std::cout << i << std::endl;
}
=
if=C2=A0 a context can only be called once the fibonacci exa= mple would not work. I assume that you mean that each invocation
<= div>of source() (context switch) updates the fcontext_t in sink is updated.=
because sink can be moved down the callstack (to sub-routine= s) you need a pointer to fcontext_t to update the structure or
you pass fcontext_t through jump_fcontext and update the structure before= you return from context::operator() of instance sink.
that&#= 39;s how boost.coroutine(2) works.

<snip>

but how sh= ould a absolute minimalistic API for stackful context switching look like?<= br>
execution_context uses a pointer that i= s updated at each context switch, e.g.
= execution_context::operator() is implemented like:

void operator()( void * vp) {
=C2=A0 ptr from( this);
=C2=A0 = current.swap( from); // *this becomes current execution-context
=C2=A0 i= ntptr_t ret =3D jump_fcontext( & from, this, vp); // resume *this
= =C2=A0 return reinterpret_cast< void * >( ret); // return parameter t= ransferred from *this
}

in contr= ast to context<> execution_context doesn't know its predecessor o= r successor.
you criticize that current= is a static pointer (that must be thread-local because we operate in a mul= ti-threaded env).
please note that this= is a library implementation, it might be possible that a compiler can impl= ement execution_context in a
more effic= ient way.
at least the main aim should = be to design a really minimalistic API useable to build higher level abstra= ctions.

--

---
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>.
--089e015383e88876050522bff496-- .