220 21607 article Path: news.gmane.org!not-for-mail From: Oliver Kowalke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: P0099 suggestion: Minimal support for asymmetric suspend/resume Date: Mon, 12 Oct 2015 20:07:47 +0200 Lines: 247 Approved: news@gmane.org Message-ID: References: <0a976368-64bd-47cd-b276-36ad5db6c2c9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11403bb21aa65e0521ec365f X-Trace: ger.gmane.org 1444673299 737 80.91.229.3 (12 Oct 2015 18:08:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 18:08:19 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCLZHP5J7MHRBB7O56YAKGQEC7T6RDY@isocpp.org Mon Oct 12 20:08:18 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZlhWB-0000uY-P9 for gclcip-std-proposals@m.gmane.org; Mon, 12 Oct 2015 20:08:16 +0200 Original-Received: by pdbfo17 with SMTP id fo17sf76540833pdb.0 for ; Mon, 12 Oct 2015 11:08: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=CtMpuw7guPsDpW2sT0uYBmHxzLfzAaZxTv8cSv9IoQI=; b=R8Sqh+4g9R7hehfD3R27VntKlXX63LEL/CJKaN36WWChtPDdNg5tbtzTaKeuq/VPjy 78rkrluopmnZzzBZmamfPN2dOyEIEztgKc3Evq7vBiGI8kC98PlerSztuNP3PRPPZzKl cvr5P6Rn/zVkAOzOXWQSGnxnvBiHeqlbxVT3bfWYEhV0QOZqOg9Y3xOrs2o9zXjYyZ9l xXXw+RwzMtz1v0Aj6oEoxtRDZOP33Jvj1HxTeEDExPhKVpdb8VG6U6Iz2HX/lDBU23W+ K63c0NPh5Tg6De45vua2IXYIeXpXoSHZeVcWHop8DQmXDUbHkSjm08jfcifD0puSxdRo Hf0A== X-Gm-Message-State: ALoCoQnDdBEMcRd+88AoldlRce7NfO/3VqJKAA0A9A1eT+NtpltFQoKbGaav0pWSW+eYpIp/tmC2 X-Received: by 10.68.142.196 with SMTP id ry4mr97952pbb.3.1444673288905; Mon, 12 Oct 2015 11:08:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.130.228 with SMTP id oh4ls1163591obb.81.gmail; Mon, 12 Oct 2015 11:08:07 -0700 (PDT) X-Received: by 10.60.35.194 with SMTP id k2mr16302645oej.67.1444673287632; Mon, 12 Oct 2015 11:08:07 -0700 (PDT) Original-Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com. [2607:f8b0:4003:c06::22b]) by mx.google.com with ESMTPS id dv2si9426892obc.99.2015.10.12.11.08.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 11:08:07 -0700 (PDT) Received-SPF: pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:4003:c06::22b as permitted sender) client-ip=2607:f8b0:4003:c06::22b; Original-Received: by oiar126 with SMTP id r126so39779106oia.0 for ; Mon, 12 Oct 2015 11:08:07 -0700 (PDT) X-Received: by 10.202.107.19 with SMTP id g19mr16146744oic.61.1444673287255; Mon, 12 Oct 2015 11:08:07 -0700 (PDT) Original-Received: by 10.76.114.199 with HTTP; Mon, 12 Oct 2015 11:07:47 -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:c06::22b 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:21607 Archived-At: --001a11403bb21aa65e0521ec365f Content-Type: text/plain; charset=UTF-8 2015-10-12 19:40 GMT+02:00 Nicol Bolas : With `execution_context`, it's easy. If the value is NULL, then that's the > first time `current` has been called on that thread. > it is not NULL - the main thread or any other thread represents an execution-context > All threads start on an execution context which is not a fiber (even if > your thread function immediately starts a fiber, there is an execution > context under it that is not a fiber). > you have to understand that a fiber or a stackful coroutine can be represented by one or two execution_contexts in the case of fibers the main-thread can be tracked as fiber (main-fiber) > If you start up fiber1 on that context, then the thread_local gets filled > in with fiber1, and fiber1's parent context is updated. > Now, let's say that fiber1 decides that it needs to do some fiber > processing of its own. So it starts up fiber2. When it does so, it's parent > context becomes fiber1, and the thread_local is updated to be fiber2. > That's fine. > What happens if fiber2 yields? The thread_local stores fiber2, so it can > get at the parent execution context and resumes it. But what happens to the > thread_local variable? > - fibers are agnostic of their predecessor and successor - a fiber can not yield, a fiber uses symmetric context switching - symmetric context switching requires that a target is given to the switch operation > And there is no reason why fibers should be prohibited from starting > fibers of their own, or from starting non-fiber contexts that *themselves* > start fibers of their own. > it is not prohibited > So long as there is no way to transform an execution_context into a fiber > (if it is indeed from a fiber), then merely having a thread_local will not > help you. > a fiber is represented by a execution_context > I have a function. Its process of execution will take multiple iterations > of the main program's loop. I don't want to start up a thread or anything > for it. I want it to execute at a specific time and place in the loop, but > I want it to be able to wait on things that will happen many loops from now. > > There are no "values" to be "yielded" (or at least, not in that sense). > This could be anything from a scene animation system in a videogame to > animating the positions of a GUI in motion (moving a widget from one > location to another to another, in a sequence). Asymmetric coroutines have > plenty of uses. > > Take the GUI-in-motion example. Normally, you'd have to code this in a > very weird way. With asymmetric coroutines, it looks like this: > > { > auto anim = widget->AnimateMoveTo(location1); > while(!anim) > coroutine::yield(); > } > > { > auto anim = widget->AnimateMoveTo(location2); > auto anim2 = widget2->AnimateMoveTo(location3); > while(!anim && !anim2) > coroutine::yield(); > } > > That code is extremely easy to read, understand, reason about, modify, and > maintain. No threading, synchronization, or anything else needs to be > involved. > > I don't want Boost.Coroutine2 and its not-at-all-asymmetric coroutines. boost.coroutine2 implements asymmetric coroutines - I don't know why you insist that it doesn't an asymmetric coroutine is characterized that it provides two operations for context switching - one operation to resume and one operation to suspend the case of boost.coroutine2 is a little bit special - the two operations are separated into to coroutine types which do always occur in a pair, e.g. the counter-part (suspend-op) is synthesized by the library > I don't want Boost.Fiber and its scheduler. I just want a function that > executes for a bit, then returns. When it's done, it's done. At the end of > the day, it's a very simple concept. > > The fact that many other languages offer asymmetric coroutines should at > least prove their utility. Not all coroutines sit there and wait on other > coroutines. > you can easily build your own coroutine-API/library utilizing execution_context -- --- 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/. --001a11403bb21aa65e0521ec365f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015= -10-12 19:40 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:<= br>
With `ex= ecution_context`, it's easy. If the value is NULL, then that's the = first time `current` has been called on that thread.

it is not NULL - the main thread or any other thread repre= sents an execution-context
=C2=A0
All threads start on an execution context which is not a fibe= r (even if your thread function immediately starts a fiber, there is an exe= cution context under it that is not a fiber).

you have to understand that a fiber or a stackful coroutine can be= represented by one or two execution_contexts
in the case of = fibers the main-thread can be tracked as fiber (main-fiber)
= =C2=A0
If you start up fiber1 on = that context, then the thread_local gets filled in with fiber1, and fiber1&= #39;s parent context is updated.
Now, let's say that fiber1 decides = that it needs to do some fiber processing of its own. So it starts up fiber= 2. When it does so, it's parent context becomes fiber1, and the thread_= local is updated to be fiber2. That's fine.
What happens if fiber2 y= ields? The thread_local stores fiber2, so it can get at the parent executio= n context and resumes it. But what happens to the thread_local variable?

- fibers are agnostic of their pred= ecessor and successor
- a fiber can not yield, a fiber uses = symmetric context switching - symmetric context switching requires that a t= arget is given to the switch operation
=C2=A0
And there is no reason why fibers shou= ld be prohibited from starting fibers of their own, or from starting non-fi= ber contexts that themselves start fibers of their own.

it is not prohibited
=C2=A0
So long as there is no way to transfo= rm an execution_context into a fiber (if it is indeed from a fiber), then m= erely having a thread_local will not help you.
<= br>
a fiber is represented by a execution_context
= =C2=A0
I have a= function. Its process of execution will take multiple iterations of the ma= in program's loop. I don't want to start up a thread or anything fo= r it. I want it to execute at a specific time and place in the loop, but I = want it to be able to wait on things that will happen many loops from now.<= br>
There are no "values" to be "yielded" (or at lea= st, not in that sense). This could be anything from a scene animation syste= m in a videogame to animating the positions of a GUI in motion (moving a wi= dget from one location to another to another, in a sequence). Asymmetric co= routines have plenty of uses.

Take the GUI-in-motion example. Normal= ly, you'd have to code this in a very weird way. With asymmetric corout= ines, it looks like this:

{
=C2=A0 auto anim =3D= widget->AnimateMoveTo(location1);
=C2=A0 while(!anim)
=C2=A0 =C2=A0 coroutine::<= /span>yield();=
}

{=
=C2=A0 auto anim =3D widget->AnimateMoveTo(location2);
=C2=A0 auto anim2 = =3D wid= get2->AnimateMoveTo(location3);
=C2=A0 while(!anim && <= span style=3D"color:#660">!anim2)
=C2=A0 =C2= =A0 coroutine::yield();
}

That code is extremely easy to rea= d, understand, reason about, modify, and maintain. No threading, synchroniz= ation, or anything else needs to be involved.

I don't want Boost= ..Coroutine2 and its not-at-all-asymmetric coroutines.

=
boost.coroutine2 implements asymmetric coroutines - I don't = know why you insist that it doesn't
an asymmetric corouti= ne is characterized that it provides two operations for context switching -= one operation to resume and one operation to suspend
the cas= e of boost.coroutine2 is a little bit special - the two operations are sepa= rated into to coroutine types which do always occur in a pair, e.g.
the counter-part (suspend-op) is synthesized by the library
=C2=A0
I don't want Boost.F= iber and its scheduler. I just want a function that executes for a bit, the= n returns. When it's done, it's done. At the end of the day, it'= ;s a very simple concept.

The fact that many other languages offer a= symmetric coroutines should at least prove their utility. Not all coroutine= s sit there and wait on other coroutines.

<= div class=3D"gmail_extra">=C2=A0you can easily build your own coroutine-API= /library utilizing execution_context

--

---
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>.
--001a11403bb21aa65e0521ec365f-- .