220 37283 <9b3171e2-70c4-4cc6-8fb6-5e180b28eb94@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Questions about P0876: fibers Date: Sat, 10 Mar 2018 17:55:48 -0800 (PST) Lines: 194 Approved: news@gmane.org Message-ID: <9b3171e2-70c4-4cc6-8fb6-5e180b28eb94@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9835_1870445691.1520733348987" X-Trace: blaine.gmane.org 1520733231 25040 195.159.176.226 (11 Mar 2018 01:53:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Mar 2018 01:53:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJMZSLKQKGQEEJMTN5Q@isocpp.org Sun Mar 11 02:53:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1euqBE-0006Ml-Ct for gclcip-std-proposals@m.gmane.org; Sun, 11 Mar 2018 02:53:44 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id r1sf4496805uae.6 for ; Sat, 10 Mar 2018 17:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=trZbU81LJQsKmaepdKv+ekerW6c/yvsR4ncYFtwzdto=; b=rQbI4bdczgJal9nZtHd5DOnRA+d1Xda5EN1ZRVJoqQ6KW8Waeb1lAJaxwWYYyctQiD 2Lusdy2pc4MmUKHIl6AnmGPmxscHJ2ZKwr8yZ7KzZpiwL+3x3B6fq4idwS0UJJ+i9ZA3 jL8yek5U4gTrNAgDGgRpT0EFcPP2Bg+EadrEGUbH59oRVsfqc+YvjxEShdzdQD3l9+v0 gn8XH/yCuLWhfNRHUoGOAQ4DhF82hlLO9PvUTL4NamWN0Zt9Y9GJzP7JbNHvkfZWSKqu 4l0G+Lt//U+5a/gENxZwl9yWcQAfbme8Es3wJxbaj01EfuQMAAFdvR5maVXQGRu3JU0a XxGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=trZbU81LJQsKmaepdKv+ekerW6c/yvsR4ncYFtwzdto=; b=OCQ+WsHWbUGyOgWPl9IpHEir4/OBZdAxTaMX9fWVPX2FybV/BrVIKpSKDzXbPZwS1y TKfhw+6cYQJFpsYLuVwEM8zm3NzK/bp4WieD3huVRDezS3r2Q+45g/PY9BWzUn+vYUhd 2aBrvvMwuq/ygga3VrTpcZV00/0ataRZxaKl0i8IGfiuUrUbVeWG9BEe0wor/h2suybL AOr7dpPpqFdmDNIFo7Ti4Oppcf8E6Ne6UV50awAVeHxudk2FbTmFwj6JzjIFaTzMdqe1 SPW9QD/PHEXcMhf7LmnciodwywsgBCD7TlFI3dtlkyTTzLKetcrbZuW0g9Dhcp89VZzc JL7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version: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=trZbU81LJQsKmaepdKv+ekerW6c/yvsR4ncYFtwzdto=; b=bdICK9ODiR1Avohj4jb9o0c0CqByAN+BIVsLEjUfH2agkFki/OhDGoTP8n9+AG9XWP OJZqzv9af6IgmysrEczSIG7y0pElOapJBDm9b3spc2R7hWOpnKEuV11gvnZVzHBcUYVl +6uCA77RloYGBmVcoAZaM19xmwEANoEE2ER76FjFmjU/4dAUcnaVdlcq59YOFLa9gsOa 9M9heyupJGjR29Pm4x0YM4orP/Oh9bziDaz0gqrP4hp7u1Lu2Cmzpd6iLuQ9imZNMXbm 8/nDTvQGys3FfL4mFP/XjwVqEh31iq0slRMZlub1LfNQbaEOnJEW9M59TyoeR2PyTLNW QX9Q== X-Gm-Message-State: AElRT7G6trnyimMyRHuyaled2C1fCFh0l3waXRWzWRneZWwvGGq7eeoM bkJpVSawcDAXYSYWdsepbVYEHg== X-Google-Smtp-Source: AG47ELv0q+O/nhiU8/ae0KGv2eRU1FrTUGmRIHc5TCEETn7h5jliel1MfZ2eyWwEQBSsVAwPdN8rPQ== X-Received: by 10.176.86.76 with SMTP id z12mr1730592uaa.36.1520733350922; Sat, 10 Mar 2018 17:55:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.158.3 with SMTP id h3ls5623348vke.11.gmail; Sat, 10 Mar 2018 17:55:49 -0800 (PST) X-Received: by 10.31.16.33 with SMTP id g33mr415430vki.13.1520733349509; Sat, 10 Mar 2018 17:55:49 -0800 (PST) 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:37283 Archived-At: ------=_Part_9835_1870445691.1520733348987 Content-Type: multipart/alternative; boundary="----=_Part_9836_113226171.1520733348988" ------=_Part_9836_113226171.1520733348988 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Saturday, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Kowalke wrote: > > 2018-03-10 21:55 GMT+01:00 Nicol Bolas >: > >> * It's not clear to me exactly how `resume_with` works, with regard to= =20 >> the underlying parts of the stack. That is, is there a way to use=20 >> `resume_with` to execute the given function, then immediately go back an= d=20 >> resume the execution of whatever was below it on the fiber's stack?=20 >> > > yes, the proposal contains an example describing how resume_with() works > > One question about this. I see that the return value from an injected=20 function is passed back to the previously executing call to=20 `resume/resume_with` on the underlying call stack. But... what happens if= =20 there *is no* underlying call stack yet. That is, you have a fresh=20 `std::fiber` which has never been `resume`d, and you call `resume_with` on= =20 it. My guess is that the return value will be passed as the *parameter* to the= =20 fiber's entry function. But I don't think your current proposal says that.= =20 Or at least, the definition of `resume_with` doesn't seem to acknowledge=20 that possibility. Oh, and one other thing. The proposal says this: When calling `resume()`, it is conventional to replace the=20 > newly-invalidated instance =E2=80=93 the instance on which `resume()` was= called =E2=80=93=20 > with the new instance returned by that `resume()` call. This helps to avo= id=20 > inadvertent calls to `resume()` on the old, invalidated instance. > That sounds like a good convention. So maybe there should be a couple of=20 global helper functions to help people adhere to it: void resume(std::fiber &&f) {f =3D std::move(f).resume();} template void resume_with(std::fiber &&f, Fn &&fn) {f =3D std::move(f).resume_with(s= td ::forward(fn));} These could be member functions (with the names `resume_inplace` and=20 `resume_with_inplace`) instead of free functions. --=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/9b3171e2-70c4-4cc6-8fb6-5e180b28eb94%40isocpp.or= g. ------=_Part_9836_113226171.1520733348988 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Saturday, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Ko= walke wrote:
<= div>
2018-03-10 21:55 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
* It's not clear to= me exactly how `resume_with` works, with regard to the underlying parts of= the stack. That is, is there a way to use `resume_with` to execute the giv= en function, then immediately go back and resume the execution of whatever = was below it on the fiber's stack?

yes, the proposal contains an example describing how resume_with() works=


One question about th= is. I see that the return value from an injected function is passed back to= the previously executing call to `resume/resume_with` on the underlying ca= ll stack. But... what happens if there is no underlying call stack y= et. That is, you have a fresh `std::fiber` which has never been `resume`d, = and you call `resume_with` on it.

My guess is that the return value = will be passed as the parameter to the fiber's entry function. B= ut I don't think your current proposal says that. Or at least, the defi= nition of `resume_with` doesn't seem to acknowledge that possibility.
Oh, and one other thing. The proposal says this:

When calling `resume()`, it is= conventional to replace the newly-invalidated instance =E2=80=93 the insta= nce on which `resume()` was called =E2=80=93 with the new instance returned= by that `resume()` call. This helps to avoid inadvertent calls to `resume(= )` on the old, invalidated instance.

That sounds like a= good convention. So maybe there should be a couple of global helper functi= ons to help people adhere to it:

void resume(std::= fiber &= ;&f) {f =3D std::move= (f<= span style=3D"color: #660;" class=3D"styled-by-prettify">).resume();}

template<typename Fn>
= void resum= e_with(std::fiber &&f, Fn &= amp;&f= n)<= span style=3D"color: #000;" class=3D"styled-by-prettify"> {f =3D std::move(f).resume_with(std::forward<Fn>(fn));}

These could be member functions (with = the names `resume_inplace` and `resume_with_inplace`) instead of free funct= ions.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/9b3171e2-70c4-4cc6-8fb6-5e180b28eb94= %40isocpp.org.
------=_Part_9836_113226171.1520733348988-- ------=_Part_9835_1870445691.1520733348987-- .