220 21621 <22794062-fc04-4458-bc5d-fc32d1466609@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: P0099 suggestion: Minimal support for asymmetric suspend/resume Date: Mon, 12 Oct 2015 13:27:30 -0700 (PDT) Lines: 506 Approved: news@gmane.org Message-ID: <22794062-fc04-4458-bc5d-fc32d1466609@isocpp.org> 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/mixed; boundary="----=_Part_5050_1863004027.1444681650356" X-Trace: ger.gmane.org 1444681658 5613 80.91.229.3 (12 Oct 2015 20:27:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 20:27:38 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBM5P6CYAKGQEVSWHADI@isocpp.org Mon Oct 12 22:27:38 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 1Zljgz-0003PE-1C for gclcip-std-proposals@m.gmane.org; Mon, 12 Oct 2015 22:27:33 +0200 Original-Received: by pacex11 with SMTP id ex11sf322149128pac.2 for ; Mon, 12 Oct 2015 13:27:32 -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=l3AYmmWOjy6yOHylvQeRkj1dbogL1H9gBJvZLQZd5C8=; b=GdUnTbHnce/nH7Xk1m2ONR3pvcyD13sjSW4KqyQRDu9x5zbfPuYrwwnlsJm5+V9iqn tW8Jxh8I9G+/eBkK1R0i6hgE0m/AA2JwpXA6lgVbG09zRfp33EV/qbiTcczjO7fPKyir rT4h8nxur23scQGyJrEN/qU5rUYIMcBkvTMu/lKzE7RfdgIH5ZsEHtWwoPuaOq/8Mc5i OUvjd2ppaOC3sec5ygZ0YgOqUku7iTf6T9RioYUn275GpQx+RT4sANlDe3w8z96klH24 9t+ImT/OZxu16hao/ugZf2QTTGhuqVClTblmhvoq67SRG2pG+02x1JpBAZ8fNhAdOtWk tUTg== 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=l3AYmmWOjy6yOHylvQeRkj1dbogL1H9gBJvZLQZd5C8=; b=Ae9fEWKmbcqvPmexbGw5GPeR6oviYBCONJwXJyBxZfp8becrGzHcz6Zi7terLEMF+4 PPXVmbdWtZ4K+TrW2w8vCAbVmc8klGGJELTo0vbII1jTR/n6JrnDtPPKD/H2pbvdAyli WL8L/u/+As8SnIfX7otHbfTfQh/O0OCWknD9y6wNj/S2pTSrlAzftF4MvpI414f+BR8P vp8OpJu9ONGVXjCkpprP26jOfo01vHy2M44Uz4Zh+/AcmZVXQOVxM/6CGFqPdhQz9FEg E/+TQ1sq/ahr+FKQ6XmXTapip/qKXJqGZt7s8ytziFwQfGQ4l61sEBnxcxlKiaEX8HWJ zcFQ== X-Gm-Message-State: ALoCoQnv0e7t/AGC4kcFflT0Rwb887uBBzZ6L+R9VOgrDwcKiyDLNCeNwjK5mV4PV/wWnfB280We X-Received: by 10.68.176.132 with SMTP id ci4mr6656152pbc.13.1444681652093; Mon, 12 Oct 2015 13:27:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.4.199 with SMTP id 190ls1481620ioe.16.gmail; Mon, 12 Oct 2015 13:27:31 -0700 (PDT) X-Received: by 10.50.131.164 with SMTP id on4mr161030igb.8.1444681651223; Mon, 12 Oct 2015 13:27:31 -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:21621 Archived-At: ------=_Part_5050_1863004027.1444681650356 Content-Type: multipart/alternative; boundary="----=_Part_5051_270390137.1444681650357" ------=_Part_5051_270390137.1444681650357 Content-Type: text/plain; charset=UTF-8 On Monday, October 12, 2015 at 2:08:10 PM UTC-4, Oliver Kowalke wrote: > > 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 > OK, the entire rest of your post is based on what may be a misuse of terminology on my part. When I said "fiber", what I meant was "the construct giving me the functionality I asked for". I based this on Gor's use of the term; I assumed that when he said "fiber", he meant something that gave me the functionality I was asking for, and he described it as such. Whether that matches your definition of what a "fiber" is or not (since the definition of these terms is far from universal), I can't say. Therefore, forget everything I said. So that we are all clear on what words mean, I will define the term *fully asymetric coroutine* as follows: *A stackful coroutine that can halt its execution, returning control to whichever execution context resumed it.* That is the behavior I want to be able to build atop `execution_context`. So here's what I said again, using proper terminology: ---- There's a problem here. It's about how that thread_local gets updated. With `execution_context`, it's easy. Initially, its an `execution_context` that represents the initial path of execution for the thread. Anytime the user resumes an execution context, the thread_local is updated accordingly. The problem with fa_coroutine (the prospective type implementing a fully asymetric coroutine atop an `execution_context`) mirroring that process is this. All threads start on an execution context which is not a fa_coroutine (even if your thread function immediately starts a fa_coroutine, there is an execution context under it that is not a fa_coroutine). So the thread_local must be empty. If you start up fa_co1 on that context, then the thread_local gets filled in with fa_co1, and fa_co1's parent context is updated. Now, let's say that fa_co1 decides that it needs to do some fa_coroutine processing of its own. So it starts up fa_co2. When it does so, its parent context becomes fa_co1, and the thread_local is updated to be fa_co2. That's fine. What happens when fa_co2 yields? The thread_local stores fa_co2, so it can get at the parent execution context and resumes it. But what happens to the thread_local variable? Because fa_co2 was executed from a fa_coroutine, when you return, the thread_local needs to be set to that fa_co. But... we have no way of knowing that fa_co2 was launched from a fa_coroutine. And there's no reason to assume that it was. There is no way to convert an execution_context into a fa_coroutine, remember? So there's no way to even test that. And there is no reason why fa_coroutines should be prohibited from starting fa_coroutines of their own, or from starting non-fa_coroutine contexts that themselves start fa_coroutines of their own. So long as there is no way to transform an execution_context into a fa_coroutine (if it is indeed from a fa_coroutine), then merely having a thread_local will not help you. ---- I believe this can be resolved, though it requires some effort: class fa_coroutine { //The caller can be either a naked execution_context or another fa_coroutine. //Ignore the fact that this isn't legal. You get the general idea. std::variant caller; std::aligned_storage_t( ec_data);} static thread_local std::optional current_fa_co; public: //copying, construction, etc as expected. void operator()() { if(current_fa_co) caller = *current_fa_co else caller = execution_context::current(); current_fa_co = *this; get_context()(); } struct update_current_fac { execution_context operator()(execution_context caller) { current_fa_co = nullopt; return caller; } execution_context operator()(fa_coroutine caller) { //The caller's caller may be a fa_coroutine or not. The //current fa_coroutine must be updated to match. fa_coroutine *new_caller = get(&caller.caller) if(new_caller) current_fa_co = *new_caller else current_fa_co = nullopt; //Deliberately bypass fa_coroutine's operator(). return *caller.get_context() } } static void yield_current() { Expects(current_fa_co); execution_context ec = visit(current_fa_co->caller, update_current_fac); ec(); //Actual yield. } friend struct update_current_fac; }; -- --- 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_5051_270390137.1444681650357 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, October 12, 2015 at 2:08:10 PM UTC-4, Oliver Kowalke wrote:
2015-10-12 19:40 GMT+02:00 Nicol Bolas <= jmck.= ...@gmail.com>:

With `execution_context`, it's easy. If the value is NULL, th= en 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
=C2=A0
All threads start on an execution context w= hich is not a fiber (even if your thread function immediately starts a fibe= r, there is an execution context under it that is not a fiber).

you have to understand that a fiber or a stackfu= l coroutine can be represented by one or two execution_contexts
in the case of fibers the main-thread can be tracked as fiber (main-fibe= r)
=C2=A0
If you st= art up fiber1 on that context, then the thread_local gets filled in with fi= ber1, and fiber1's parent context is updated.
Now, let's say tha= t fiber1 decides that it needs to do some fiber processing of its own. So i= t 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 ha= ppens if fiber2 yields? The thread_local stores fiber2, so it can get at th= e parent execution context and resumes it. But what happens to the thread_l= ocal variable?

- fibers are agnos= tic of their predecessor and successor
- a fiber can not yie= ld, a fiber uses symmetric context switching - symmetric context switching = requires that a target is given to the switch operation

OK, the entire rest of your post is based on = what may be a misuse of terminology on my part. When I said "fiber&quo= t;, what I meant was "the construct giving me the functionality I aske= d for". I based this on Gor's use of the term; I assumed that when= he said "fiber", he meant something that gave me the functionali= ty I was asking for, and he described it as such.

Whether that match= es your definition of what a "fiber" is or not (since the definit= ion of these terms is far from universal), I can't say.

Therefor= e, forget everything I said. So that we are all clear on what words mean, I= will define the term fully asymetric coroutine as follows:

<= u>A stackful coroutine that can halt its execution, returning control to wh= ichever execution context resumed it.

That is the behavior I wan= t to be able to build atop `execution_context`. So here's what I said a= gain, using proper terminology:

----

There's a problem he= re. It's about how that thread_local gets updated.

With `executi= on_context`, it's easy. Initially, its an `execution_context` that repr= esents the initial path of execution for the thread. Anytime the user resum= es an execution context, the thread_local is updated accordingly.

Th= e problem with fa_coroutine (the prospective type implementing a fully asym= etric coroutine atop an `execution_context`) mirroring that process is this= ..

All threads start on an execution context which is not a fa_corout= ine (even if your thread function immediately starts a fa_coroutine, there = is an execution context under it that is not a fa_coroutine). So the thread= _local must be empty. If you start up fa_co1 on that context, then the thre= ad_local gets filled in with fa_co1, and fa_co1's parent context is upd= ated.

Now, let's say that fa_co1 decides that it needs to do som= e fa_coroutine processing of its own. So it starts up fa_co2. When it does = so, its parent context becomes fa_co1, and the thread_local is updated to b= e fa_co2. That's fine.

What happens when fa_co2 yields? The thre= ad_local stores fa_co2, so it can get at the parent execution context and r= esumes it. But what happens to the thread_local variable?

Because fa= _co2 was executed from a fa_coroutine, when you return, the thread_local ne= eds to be set to that fa_co. But... we have no way of knowing that fa_co2 w= as launched from a fa_coroutine. And there's no reason to assume that i= t was. There is no way to convert an execution_context into a fa_coroutine,= remember? So there's no way to even test that.

And there is no = reason why fa_coroutines should be prohibited from starting fa_coroutines o= f their own, or from starting non-fa_coroutine contexts that themselves sta= rt fa_coroutines of their own.

So long as there is no way to transfo= rm an execution_context into a fa_coroutine (if it is indeed from a fa_coro= utine), then merely having a thread_local will not help you.

----
I believe this can be resolved, though it requires some effort:
class fa_coroutine{<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 = //The call= er can be either a naked execution_context or another fa_coroutine.<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 = //Ignore t= he fact that this isn't legal. You get the general idea.
=C2=A0 =C2=A0 std::variant<execution_context, fa_coroutine> caller;
=C2=A0 =C2=A0 std::aligned_storage_t<sizeof(execution_context), alignof(= execution_= context) ec_data;

=C2=A0 =C2=A0 e= xecution_context *ge= t_context(= ) <= span style=3D"color: #660;" class=3D"styled-by-prettify">{return static_cast<execution_context>(ec_data);}

=C2=A0 =C2=A0 static thread_local std::optional<fa_coroutine> current_fa_co;

public:
=C2=A0 =C2=A0 //copying, construction, etc as expected= ..

= =C2=A0 =C2=A0 void <= /span>operator()()
=C2=A0 =C2=A0 <= /span>{
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 if(current_fa_co= )
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 caller =3D <= /span>*current_fa_co
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 caller =3D execution_context::current();
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 current_fa_co =3D *this;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 get_context()();=
=C2=A0 =C2=A0 }<= br>
=C2=A0 =C2=A0 struct update_current_fac
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 execution_context = operator()(execution_context <= /span>caller)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 {<= /span>
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 current_fa_co =3D nullopt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= span style=3D"color: #008;" class=3D"styled-by-prettify">return caller;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 execution_context operator()(fa_coroutine caller)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 //The caller's caller may be a fa_coroutine or not. The
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 //current fa_coroutine must be updated to match.
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 fa_coroutine *new_caller =3D = get<fa_= coroutine>(&c= aller.caller<= span style=3D"color: #660;" class=3D"styled-by-prettify">)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 if(new_ca= ller)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 current_fa_co =3D *new_caller
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 els= e
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 current_fa_co <= span style=3D"color: #660;" class=3D"styled-by-prettify">=3D nullopt;
=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 //Deliberately= bypass fa_coroutine's operator().
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= /span>return *caller.get_context()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0
=C2=A0 =C2=A0 <= /span>static void yield_current()
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <= /span>Expects(current_fa_co);
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 execution_context ec =3D visit(curre= nt_fa_co-&= gt;caller<= /span>,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 update_current_fac);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ec(); //Actual yield.
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0
=C2=A0 =C2= =A0 friend= struct update_current_fac;
};
=

--

---
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_5051_270390137.1444681650357-- ------=_Part_5050_1863004027.1444681650356-- .