220 21567 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0099 suggestion: Minimal support for asymmetric suspend/resume Date: Sun, 11 Oct 2015 21:57:35 -0700 (PDT) Lines: 151 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4188_1425637774.1444625855931" X-Trace: ger.gmane.org 1444625859 14024 80.91.229.3 (12 Oct 2015 04:57:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 04:57:39 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBQP35SYAKGQEKBBKHXY@isocpp.org Mon Oct 12 06:57:39 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZlVB4-0005NZ-Mv for gclcip-std-proposals@m.gmane.org; Mon, 12 Oct 2015 06:57:38 +0200 Original-Received: by iodv82 with SMTP id v82sf114378647iod.0 for ; Sun, 11 Oct 2015 21:57:37 -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=pZNRm1I3C1wO0Syh+tE6TyzUvwIJfvEj4eEfNiq4GCs=; b=nc1ESjbM3EVyAGFQVFWApvBwOrJQi9xejvxvCnkkOaEA1i0zR0YZZM6Gouknqjr7QR 0C/bBY3fhWGndEBC7S0JgFwAMXyZavTG98nP+eJ1xdK9OJXMt1CO68jW6gEU72kn1sat Lgj+bXvOXzDPkLCbZiND/2iCYw3/iM6rXg+BisRzz0QihDvb6WOxzpfPZ7KZbKbAWmvD Qfa8/uMEj2IwgDl+dyDx5kECgfAc/OUeH4FMFxijg+oNsjFDbZBqbeJ75f+pGxpUdl67 vf7b8clbzOZB9nZ5sbvYe+GV+MdLJwrUaVLeuOjXhkAGhLmeuGMSnGEoCzngtjfR/oIW PtpQ== 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=pZNRm1I3C1wO0Syh+tE6TyzUvwIJfvEj4eEfNiq4GCs=; b=j4KwCBGKRoYNdMdzKnGYARS/ewm1HhBpnjffKcksLWpOhnVWeVQJR7L+xRex/PCB8u fZtK03G9U5wGpdv5P/l8whuoa8nbfycDb7PZWyjTM22WY0i2GCOLz0saLCCMmAC7rYZQ VX6muSueq3lTPD/99p1k2wkeOiaHEAe4g143W+3EvuGUzXE2+JLiDCAbk8mMpcr9Cg0w P+tWC9sDo7uIPFm0jMlrIs+whDkDszf5etr3vQG0sGVK/clWEy1rnsc/SIJ6jXPHZOmg oqOykDShFu0CRhbVT4BXeZvXvmOzgYFK0hmA382Y4duFCVuHttk4BJXNIUepK5LrFmWc /eHQ== X-Gm-Message-State: ALoCoQmxHINpL3nrOTkr9u/9gLnYAgOAOaYYShgWVpr5uVNvoyLvnTLajoh/NlBBFZ88/ktUkhc7 X-Received: by 10.182.72.166 with SMTP id e6mr22959719obv.47.1444625857511; Sun, 11 Oct 2015 21:57:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.88.42 with SMTP id bd10ls1024811igb.27.gmail; Sun, 11 Oct 2015 21:57:36 -0700 (PDT) X-Received: by 10.50.142.9 with SMTP id rs9mr109052igb.6.1444625856947; Sun, 11 Oct 2015 21:57:36 -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:21567 Archived-At: ------=_Part_4188_1425637774.1444625855931 Content-Type: multipart/alternative; boundary="----=_Part_4189_1210257535.1444625855931" ------=_Part_4189_1210257535.1444625855931 Content-Type: text/plain; charset=UTF-8 On Monday, October 12, 2015 at 12:53:04 AM UTC-4, Nicol Bolas wrote: > > With P0057 and P0099, we have two choices for our coroutine needs: > asymmetric, stackless and symmetric, stackful. > > Having a stack and not having a stack are more or less orthogonal relative > to the symmetry of coroutine execution. Well, not really; it'd be very > difficult to have stackless symmetric coroutines. But both symmetric and > asymmetric are legitimate designs for stackful coroutines. > > I agree that it is important to support symmetric stackful coroutines, due > to the context switching overhead. You'll get no arguments here. > > The problem is that it's *really* hard to support asymmetric coroutines > given the current design. There is not only no linkage between the calling > context and the callee, there is no way to create such linkage. > > Oh sure, you can have a lambda function that captures the calling context. > The problem is that the lambda would then have to pass that up the entire > call stack to whomever it is that actually suspends. > > Not everyone suspends in the base function, after all. > > Again, I agree that it should not be the default case. But give us at > least *something* to allow for the asymmetric case. > > Possible suggestions: > > 1) Give `execution_context` a function to suspend the current context, > resuming the previous one. The previous context being the context that was > current when it called our `operator()` function. > > This naturally requires that `execution_context` store a reference to a > previous context. If the previous context was ended in the meantime, it's > no different from any case where you attempt to resume a dead handle. > > 2) If having a named function for this is considered bad form, simply give > `execution_context` a function that returns the previous context. That way, > it can use `operator()` the normal way. Again, this requires that > `execution_context` store a reference to the previous context. > > 3) If having `execution_context` store the previous context is just too > much... well, give us a pointer. Have `execution_context` be able to be > transformed into a pointer (much like P0057's coroutine_handle can be). > Every `execution_context` which refers to the same state has the same > pointer, which will be different for every distinct context state that > exists. Obviously, `execution_context`s which have finished (operator bool > returns false) return nullptr. > > The idea here is that the user can associate the pointer for an > `execution_context` with the execution_context that will call it. Yes, this > would have to be done via a global table, which is generally a bad idea. > > But at least it would *work*. If we can't have `execution_context` track > the caller for us, it would at least allow us to track it ourselves. > Oh, and a word on option #3: P0057 allows `coroutine_handle`s to be transformed to/from pointers, so that they can be used as callback data values in C-style APIs. That may be important in some specialized cases when wanting to yield across C-style APIs. So there are good reasons for having it besides supporting asymmetric coroutines. While I'd prefer option #2, #3 will at least be functional. -- --- 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_4189_1210257535.1444625855931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, October 12, 2015 at 12:53:04 AM UTC-4, Nicol Bolas wrote:
With P0057 and P0099= , we have two choices for our coroutine needs: asymmetric, stackless and sy= mmetric, stackful.

Having a stack and not having a stack are more or= less orthogonal relative to the symmetry of coroutine execution. Well, not= really; it'd be very difficult to have stackless symmetric coroutines.= But both symmetric and asymmetric are legitimate designs for stackful coro= utines.

I agree that it is important to support symmetric stackful c= oroutines, due to the context switching overhead. You'll get no argumen= ts here.

The problem is that it's really hard to support = asymmetric coroutines given the current design. There is not only no linkag= e between the calling context and the callee, there is no way to create suc= h linkage.

Oh sure, you can have a lambda function that captures the= calling context. The problem is that the lambda would then have to pass th= at up the entire call stack to whomever it is that actually suspends.
Not everyone suspends in the base function, after all.

Again, I ag= ree that it should not be the default case. But give us at least somethi= ng to allow for the asymmetric case.

Possible suggestions:
1) Give `execution_context` a function to suspend the current context, re= suming the previous one. The previous context being the context that was cu= rrent when it called our `operator()` function.

This naturally requires that `execution_context` store a reference to a=20 previous context. If the previous context was ended in the meantime,=20 it's no different from any case where you attempt to resume a dead=20 handle.

2) If having a named function for this is considered bad for= m, simply give `execution_context` a function that returns the previous con= text. That way, it can use `operator()` the normal way. Again, this require= s that `execution_context` store a reference to the previous context.
3) If having `execution_context` store the previous context is just too m= uch... well, give us a pointer. Have `execution_context` be able to be tran= sformed into a pointer (much like P0057's coroutine_handle can be). Eve= ry `execution_context` which refers to the same state has the same pointer,= which will be different for every distinct context state that exists. Obvi= ously, `execution_context`s which have finished (operator bool returns fals= e) return nullptr.

The idea here is that the user can associate the = pointer for an `execution_context` with the execution_context that will cal= l it. Yes, this would have to be done via a global table, which is generall= y a bad idea.

But at least it would work. If we can't hav= e `execution_context` track the caller for us, it would at least allow us t= o track it ourselves.

Oh, and a word on opti= on #3: P0057 allows `coroutine_handle`s to be transformed to/from pointers,= so that they can be used as callback data values in C-style APIs. That may= be important in some specialized cases when wanting to yield across C-styl= e APIs. So there are good reasons for having it besides supporting asymmetr= ic coroutines.

While I'd prefer option #2, #3 will at least be f= unctional.

--

---
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_4189_1210257535.1444625855931-- ------=_Part_4188_1425637774.1444625855931-- .