220 31425 article Path: news.gmane.org!.POSTED!not-for-mail From: Oliver Kowalke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: P0534: call/cc, type safety and exceptions Date: Sat, 4 Mar 2017 21:56:29 +0100 Lines: 372 Approved: news@gmane.org Message-ID: References: <3a57e294-7254-4358-828d-c9f7757f5295@isocpp.org> <4e6c13b2-4286-4df8-989b-97cbf3bf1cc7@isocpp.org> <312d04a6-8b20-4bf5-8357-507ba9938e84@isocpp.org> <762243ed-0c31-461d-b6fd-fdb8759857b2@isocpp.org> <33bda80d-c83a-4cb9-a67f-5c7b2658e060@isocpp.org> <113327fb-b26a-421e-9b07-9a2045c4178f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c1bcee8b8502c0549ede615 X-Trace: blaine.gmane.org 1488661014 13485 195.159.176.226 (4 Mar 2017 20:56:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 20:56:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCLZHP5J7MHRBFGU5TCQKGQELE6CP5A@isocpp.org Sat Mar 04 21:56:48 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckGjP-0002qo-RF for gclcip-std-proposals@m.gmane.org; Sat, 04 Mar 2017 21:56:48 +0100 Original-Received: by mail-pg0-f71.google.com with SMTP id 65sf165646615pgi.7 for ; Sat, 04 Mar 2017 12:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=6eBoRuJ1UhsI1R1jF2ySfPV7gScSL8FWFUzspuf9W/c=; b=KB6S8HWcu/hBH/+VE3cuiHji0q2i6Hcd8+shLdVb5tpDYb4jc42W7sPegIk43Z90lJ RylTAALW9eUbk4bXNNF3AH9bXv1/8Ukv90VXC1ZJRlsdUs0TvIu1tXRZvzDwAJo9jy4S m/cpQaFBQlgiWbX1amgiKEUym/W+FpNDejksbnhKyAGFkdCNJebWos4sQFkK2Z5AgdPj gYDimCV/9v/Dfk5tpY/21P9/hoqy1YYZrOcR9/Em03fqJDzbGR1NfkcVYCrGEi0KjXmC ZISBNtb2XD1CrBS2V3ScdpC+p5rR5hmfmpEfB+AsmsgFNjqlxy/7WZD9by+JJO9ZS3iM fiEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=6eBoRuJ1UhsI1R1jF2ySfPV7gScSL8FWFUzspuf9W/c=; b=nkdwbUqIwGM4s0cvKDO7khrTQwi1rqJWanPPFpJjkFlACPQtIymF0SuOPQEyBWecc4 VFYMGGLL/0kMs+u5fB4D37sgSv2p+YEJ0CC7cuW/nfftO019srg+Nw1Zql3kidFNCYAn Ctr6OFELSjdzuQHp07IS5QcAYRF8l2gvkPq+HY3WGb3G6mui0seFAXOyPpi2y4S4XQmz ZB5nVrr9bh0NYiuX1MOUwQ0/XUC4xOgoVbaVxgBSuQ1yJRj2f6fRpcPt6KCPkoL/iHiL nicYZNbi1SwDTuB5jifbT0z02vjTnOkaNk2FKRwYYpbTMrn5GevRokE5WKOZcPsF8ilW /4+g== X-Gm-Message-State: AMke39nd6wdU1Wqn4xShY+QhwH99vwqjrHUwnMt55u5dHIw2dIkCbhe3SRJzbDB3iALBkA== X-Received: by 10.98.69.130 with SMTP id n2mr1942873pfi.9.1488661013360; Sat, 04 Mar 2017 12:56:53 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.34.211 with SMTP id i202ls3689640ioi.51.gmail; Sat, 04 Mar 2017 12:56:51 -0800 (PST) X-Received: by 10.98.63.140 with SMTP id z12mr11693443pfj.129.1488661010993; Sat, 04 Mar 2017 12:56:50 -0800 (PST) Original-Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com. [2607:f8b0:400e:c00::22e]) by mx.google.com with ESMTPS id e5si14334486pgd.111.2017.03.04.12.56.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 12:56:50 -0800 (PST) Received-SPF: pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:400e:c00::22e as permitted sender) client-ip=2607:f8b0:400e:c00::22e; Original-Received: by mail-pf0-x22e.google.com with SMTP id j5so44602395pfb.2 for ; Sat, 04 Mar 2017 12:56:50 -0800 (PST) X-Received: by 10.99.164.18 with SMTP id c18mr11375551pgf.40.1488661010466; Sat, 04 Mar 2017 12:56:50 -0800 (PST) Original-Received: by 10.100.182.227 with HTTP; Sat, 4 Mar 2017 12:56:29 -0800 (PST) In-Reply-To: <113327fb-b26a-421e-9b07-9a2045c4178f@isocpp.org> X-Original-Sender: oliver.kowalke@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:400e:c00::22e as permitted sender) smtp.mailfrom=oliver.kowalke@gmail.com; dmarc=pass (p=NONE sp=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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:31425 Archived-At: --94eb2c1bcee8b8502c0549ede615 Content-Type: text/plain; charset=UTF-8 2017-03-04 20:04 GMT+01:00 Bengt Gustafsson : > I don't see your point - accessing a register if verry fast (1 CPU cycle I >> guess). >> > The point is that if the feature does not have a large performance gain > compared to not having it, and if it does not avoid a complex > synchronization problem then why have it? I don't see that you have shown > any major performance or synchronization gain. > I don't understand what you try to tell me > > The data transfer as proposed in P0534 (and used for coroutine and fiber >> implementation) does provide some kind of type-safety and no overhead if no >> data are transferred. >> > While ideas in the direction of my Generator class offers compile time > type safety and negligable overhead even if used! > generators provide asynchronous context switching which is always less efficient than synchronous > Not to mention a smaller API. > it's not > - in foo you resume c2: c2() >> > ok, a bit odd but doable. > why is it odd? > > - in bar you jump to main() >> > Unless you involve setjmp/longjmp I don't see a way fot this to happen > callcc() does similiar things like setjmp/longjmp - actually callcc() creates a new stack and a new context and exchanges stack and instruction pointer > What can happen is that foo gives bar access to its stored continuation > and bar uses this to transfer control to main after its c1() call. > I don't get it foo can not give its continuation to bar while foo is running foo is supended by calling callcc() or continuation::operator() and the invocation of this functions generate a continuation of foo > And sure enough c1 now refers to bar after its second context switch. Yes > this seems to be what you refer to. > > >> - that means you return from c1() in main() >> - if you call c1() in main() you do resume bar() instead of foo() >> > Yes. This can happen if you store the continuations in global variables > no, global vars are not needed > Isn't this why we want to abstract the continuation level into higher > level abstractions which are easier to understand and where these types of > oddities are easy to avoid. > I would say no - higher level astractions defined how continuations interact > The only gain with the assignment is as a reminder of "next time this > continuation will continue executing somewhere else". But as that always > happens and you can not make something else happen by NOT doing the > assignment (except dropping a valuable asset) it seems rather error prone... > I don't get it > no - resume the context and then, if you are in the resumed context, >> create a new stack frame and execute your supplied function (that might >> throw) >> > OK, I understand what it does, my question was why this is useful. > yes > Yes, that is how I understood it. This is what would happen if you forget > to assign the returned continuation to your variable, I assume ;-) > right > So the only use case for invoke_on_top() that you have produced is in fact > equivalent to destroying the continuation object. > no > Given that you can't access data in underlying stack frames > you can pass data from the fucntion executed ontop of the context to the underlying stack frame > continuation c; > > fun() > c() > fun() is executed on the current stack (and in the current context - lets say main() for instance) c() resumes c, e.g switches execution to the stack and context c is related to and > c.invoke_on_top(fun); > resumes c and invokes fun on the stack c is related to == fun() is executed in the context of c > Well, there may be some difference if fun throws, > if fun() throws fun() c() -> c() is not executed; exeception is thrown in the context of main() for instance c.invoke_on_top(fun); -> exeception is thrown inside c and will terminate c if not catched Ok, maybe you only see this as a method of throwing an exception in the > other stack, > no I would have thought that the main use would be to allow a pool of fibers > to be used for executing arbitrary code. > you nixing up concepts - callcc() is not a fiber, but fibers can be implemented using callcc() (see boost.fiber as an example) > The main reason for not doing new callcc() calls each time would be to > avoid having to allocate stacks each time. > callcc() is factory function of continuations, it generates a new stack and context > If this is the use case it seems that the stack rather than the > continuation is the object to preserve and pool. > the stack is actually the continuation - if continuation::operator() is called the stack pointer (stored inside continuation) is assigned to the stack pointer and the instruction pointe ris poped from it -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-oL6F%2B99T_ySpL%2BDjuARzSE5gSWkPqyZYGWAyhs%3DGOgw%40mail.gmail.com. --94eb2c1bcee8b8502c0549ede615 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017= -03-04 20:04 GMT+01:00 Bengt Gustafsson <bengt.gustafsson@beam= ways.com>:
=
I don't see your point - access= ing a register if verry fast (1 CPU cycle I guess).
The point is that if the feature does not have= a large performance gain compared to not having it, and if it does not avo= id a complex synchronization problem then why have it? I don't see that= you have shown any major performance or synchronization gain.
<= /blockquote>

I don't understand what you try to tell= me
=C2=A0

The data transfer as pr= oposed in P0534 (and used for coroutine and fiber implementation) does prov= ide some kind of type-safety and no overhead if no data are transferred.
While ideas in the direction = of my Generator class offers compile time type safety and negligable overhe= ad even if used!

=C2=A0generato= rs provide asynchronous context switching which is always less efficient th= an synchronous
=C2=A0
Not to mention a smaller API.

it's not
=C2=A0
- in foo you resume c= 2: c2()
ok, a bit odd b= ut doable.=C2=A0

why is it odd?=
=C2=A0

- in bar you jump to main()
=
Unless you involve setjmp/longjm= p I don't see a way fot this to happen
callcc() does similiar things like setjmp/longjmp - actually ca= llcc() creates a new stack and a new context and exchanges stack and instru= ction pointer
=C2=A0
What can happen is that foo gives bar access to i= ts stored continuation and bar uses this to transfer control to main after = its c1() call.

I don't get = it

foo can not give its continuation to bar while foo is running
foo is supended by calling callcc() or continuation::operator()= and the invocation of this functions generate a continuation of foo
=C2=A0
And sure enough c1 now refers to bar after its second cont= ext switch. Yes this seems to be what you refer to.
=C2=A0
- that means you return from c1() in main()
- i= f you call c1() in main() you do resume bar() instead of foo()
Yes. This can happen if you store t= he continuations in global variables

no, global vars are not needed
=C2=A0
Isn't this = why we want to abstract the continuation level into higher level abstractio= ns which are easier to understand and where these types of
odditi= es are easy to avoid.

I would s= ay no - higher level astractions defined how continuations interact

= =C2=A0
The only gain with the assignment is as a reminder of &= quot;next time this continuation will continue executing somewhere else&quo= t;. But as that always happens and you can not make something else happen b= y NOT doing the assignment (except dropping a valuable asset) it seems rath= er error prone...

I don't g= et it
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
no - resume the context and then, if= you are in the resumed context, create a new stack frame and execute your = supplied function (that might throw)
OK, I understand what it does, my question was why this is u= seful.=C2=A0

yes
= =C2=A0
Yes, that= is how I understood it. This is what would happen if you forget to assign = the returned continuation to your variable, I assume ;-)

right
=C2=A0
So the on= ly use case for invoke_on_top() that you have produced is in fact equivalen= t to destroying the continuation object.

<= /div>
no
=C2=A0
Given that you can't access data i= n underlying stack frames

you = can pass data from the fucntion executed ontop of the context to the underl= ying stack frame
=C2=A0
continuation c;

fun()=
c()

fun() is execute= d on the current stack (and in the current context - lets say main() for in= stance)
=C2=A0
c() resumes c, e.g switches exec= ution to the stack and context c is related to

<= div>and
c.invoke_on_top(fun);

resumes c and invokes fun on the stack c is related to =3D=3D fun(= ) is executed in the context of c

=C2=A0
Wel= l, there may be some difference if fun throws,

if fun() throws

fun()
c()
-> c() is not executed; exeception is thrown in the context= of main() for instance

c.invoke_on_top(fun);
-> ex= eception is thrown inside c and will terminate c if not catched

Ok, maybe you only see this as a method of throwing an= exception in the other stack,

= no

I would have thought that the main use would be to = allow a pool of fibers to be used for executing arbitrary code.
=

you nixing up concepts - callcc() is not a= fiber, but fibers can be implemented using callcc() (see boost.fiber as an= example)
=C2=A0
The main reason for not doing new callcc(= ) calls each time would be to avoid having to allocate stacks each time.

callcc() is factory function of c= ontinuations, it generates a new stack and context
=C2=A0
I= f this is the use case it seems that the stack rather than the continuation= is the object to preserve and pool.

<= /div>
the stack is actually the continuation - if continuation::operato= r() is called the stack pointer (stored inside continuation) is assigned to= the stack pointer and the instruction pointe ris poped from it
=C2=A0

--
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/CA%2Bwfc1= -oL6F%2B99T_ySpL%2BDjuARzSE5gSWkPqyZYGWAyhs%3DGOgw%40mail.gmail.com. --94eb2c1bcee8b8502c0549ede615-- .