220 14274 <468f75af-f267-4758-b345-be36aaf2b966@isocpp.org> article Path: news.gmane.org!not-for-mail From: Gor Nishanov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: comment on n4244 Date: Tue, 28 Oct 2014 06:10:07 -0700 (PDT) Lines: 107 Approved: news@gmane.org Message-ID: <468f75af-f267-4758-b345-be36aaf2b966@isocpp.org> References: <5d78c59b-4d67-45f6-9d99-8c4beeeac055@isocpp.org> <5344687e-e1de-4205-885c-b5c2f9580129@isocpp.org> <187da710-8adc-4516-bf64-263951503bc7@isocpp.org> <42ddf641-27c7-42a5-ab1c-772667797e5b@isocpp.org> <05a08ac6-f9b8-4ebb-9cb8-9a37a6fd4527@isocpp.org> <3ff7fe35-37c6-4f95-8701-1798b0112c10@isocpp.org> <934c6ace-40cc-484a-96ea-b05aff88482d@isocpp.org> <9082f48e-088c-4d96-99b2-2ad6e0721283@isocpp.org> <81ae79cc-453a-4cff-9e18-4b5a7914ba1a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4040_886394770.1414501807538" X-Trace: ger.gmane.org 1414501824 9158 80.91.229.3 (28 Oct 2014 13:10:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2014 13:10:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC47RF4IW4GRBMFLX2RAKGQEDAICMOQ@isocpp.org Tue Oct 28 14:10:17 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xj6XK-0007Wr-0x for gclcip-std-proposals@m.gmane.org; Tue, 28 Oct 2014 14:10:10 +0100 Original-Received: by mail-ie0-f198.google.com with SMTP id tr6sf2461644ieb.9 for ; Tue, 28 Oct 2014 06:10:09 -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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=Ll7axaqbv5nWNcm4nhLbs5RNnxYPTzGz88xbJQ5ZWg0=; b=cEdTevon7RxASGrRoiQ3PgJmIPLvqXm6ChrhH6qGaQs69D/cklWTknRmJ8BTZ3F3fA JJUlKot4kHhZE6RV1CoO02X8n2zmhhyr6JHPgcgIoNSmg/54teW283KIKAmtJAsR2O9b xvb22WoAL3J3Jhu9KdKdt+SBJz4rAzVd8b/eOLevdC/xqpOdjbVQbT/dDgYHUAFxDASN ZzQiyTPzZVTDLz3jlcbMTJZIbdv9umvzFjIVhkTdLR/wIka8RGINw6dKTgCrLpyoF45t O3JPv/+pcJPfqUAkE8r0J80jnNr8yRtmJUMrrQMH8Iqoh2k3Vg2PXIfYThNDfDYPsxO7 aQ6A== 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:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=Ll7axaqbv5nWNcm4nhLbs5RNnxYPTzGz88xbJQ5ZWg0=; b=JNv2+rF24krNxi4u8IuQ9geR+WwyUFeBkdB/jxvoAh123zVPs2n0dwK5F6aPsVuvTk BE7aCvUFvb5zXhJw5Nz7SMejRsYOu+86B8u4p0ORdlx+HxYYDC/Hhqe4MTvjW99wE8vM Ue2nPjcsg7puKAR7aWOZk9JYYS4yUAxnt12EvuDmsfVK7wjHXk25rNXqwvWbJKZxEygH 2UitxIK3+YJuNKKnE2W2qdRmjSn29/T/xRUa6hiZyS5so/fDDorJnQKaIB779itNgKK/ CcWZ/mRtdyMSSAAoZCMxJMq4tF6AXStumfuISG1kOxpOBVgLMvKB6gJCLqHllCTe3M0H eO4w== X-Gm-Message-State: ALoCoQmWiukdk3qELnqu9Dr3VeVXnsghWUddv5W8FR/DJj5ax/HmvpIfgn+Du6BJislu+AWp53B1 X-Received: by 10.42.7.72 with SMTP id d8mr2658138icd.20.1414501809048; Tue, 28 Oct 2014 06:10:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.137.34 with SMTP id l34ls96257iod.76.gmail; Tue, 28 Oct 2014 06:10:08 -0700 (PDT) X-Received: by 10.50.141.138 with SMTP id ro10mr328488igb.16.1414501808349; Tue, 28 Oct 2014 06:10:08 -0700 (PDT) In-Reply-To: X-Original-Sender: GorNishanov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:14274 Archived-At: ------=_Part_4040_886394770.1414501807538 Content-Type: text/plain; charset=UTF-8 Ville: I started with the design similar to N4244, I called it lambda* and after experimenting with it I came to a conclusion that syntactic sugar on top, such as N4134 is necessary for convenience and safety. Conceptually, there is an unspecified lambda* sitting inside of N4134, leaving it unspecified allows to do more optimization than what would be possible. > it's not likely to be a practical limitation. > N4244 explains what you need to do in such cases, and those restrictions > seem fine to me. > I believe that having a stationary coroutine state is important to do async I/O patterns efficiently and with minimal number of extraneous heap allocations. To achieve that you need to place lambda* / N4244 on a heap or embed it in some other heap allocated class or a global variable. Either embedding (example in section 5 of N4244) or allocating it on the heap, will require a move. Look at the steps involve. 1st we need to make a helper function returning a lambda. auto foo() { return []() resumable { ....} }; than, for the case of embedded, you will say: struct Parent { decltype(foo()) foo_; Parent(decltype(foo()) foo) : foo_(std::move(foo)) {} // move? I also considered moving a lambda* that start executing unsafe in general case, due to aliases to local state of the running / suspended coroutine -- --- 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_4040_886394770.1414501807538 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ville:

I started with t= he design similar to N4244, I called it lambda* and after experimenting wit= h it I came to a conclusion that syntactic sugar on top, such as N4134 is n= ecessary for convenience and safety.
 
Conceptuall= y, there is an unspecified lambda* sitting inside of N4134, leaving it= unspecified allows to do more optimization than what would be possible.  
it's not likely to be a practical limitation.
N4244 explains what you need to do in such cases, and those restriction= s
seem fine to me.

I believe that having a stationary cor= outine state is important to do async I/O patterns efficiently and with min= imal number of extraneous heap allocations.
To achieve that you n= eed to place lambda* / N4244 on a heap or embed it in some other heap alloc= ated class  or a global variable.

Either embe= dding (example in section 5 of N4244) or allocating it on the heap, will re= quire a move.

Look at the steps involve.

1st we need to make a helper function returning a lambda.

auto foo() { return []() resumable { ....} };

than, for the case of embedded, you will say:

struct Parent {
     decltyp= e(foo()) foo_;
     Parent(decltype(foo()) fo= o) : foo_(std::move(foo)) {} // move?


I also considered moving a lambda* that start executing unsafe in genera= l case, due to aliases to local state of the running / suspended coroutine<= /div>




--

---
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_4040_886394770.1414501807538-- .