220 31422 <113327fb-b26a-421e-9b07-9a2045c4178f@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: P0534: call/cc, type safety and exceptions Date: Sat, 4 Mar 2017 11:04:15 -0800 (PST) Lines: 456 Approved: news@gmane.org Message-ID: <113327fb-b26a-421e-9b07-9a2045c4178f@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1214_2074571044.1488654255895" X-Trace: blaine.gmane.org 1488654264 8617 195.159.176.226 (4 Mar 2017 19:04:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 19:04:24 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRBMM75TCQKGQEQF65QTQ@isocpp.org Sat Mar 04 20:04:17 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f200.google.com ([209.85.192.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckEyS-0000yM-Cd for gclcip-std-proposals@m.gmane.org; Sat, 04 Mar 2017 20:04:12 +0100 Original-Received: by mail-pf0-f200.google.com with SMTP id l66sf46467547pfl.6 for ; Sat, 04 Mar 2017 11:04:18 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=gX7zL3g1zMv2h3EcawMsrGn0aZCSBVC62oN5fDe8gUE=; b=HpDXvLCecv/P5gvHnTEADMOIdwhm7YZq4LFMgzF2Q8mQL2VZUTpx7Rir7Uce+uCEAb +MPg1Tsw1yIeqykrNdGJ0SfIowZ6S7JiGB7WTanbjwtas8c//tyKOpcV2bOYxqXI0zo0 tDEqOtFcKJw9c6KwzfZXVEbNCSAwXNERuDopIDyVKB5XBrMFSfSovdUxynYdpicRAgUB aZInnMNLJJJHmR/6UCJS0A45P/43iWJBCkNCMiq1/9b20gONvf+4Mn/FMDx8Mv0EzEmd 4ELvAX0JvoJY3DUnmL54RpAUp7/rCG2j3FbHet0lUjeY8WsEt1vnbZEvXDOkToNaBrjJ rdhg== 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=gX7zL3g1zMv2h3EcawMsrGn0aZCSBVC62oN5fDe8gUE=; b=TNMz4FTPdhj5lFoK8PKTvALa8Jgor8PFtn+okoI7KuFFE4JAKr/5RXoJ1R/FAXX+Hb EiDCLSzcrlzBQnGgmstGnb6vtjUTmhL4tWI3M43lCLKfbxOm05Iie9meUyFey1OUdN3a YN+IHts8DWeyPoY8qQTosKKMKs4mGt/xUCIpKFvB8VWw0dTmSGTNSdSGQSwtTGVtZwVh +cOKN/9LX5YR0MWnmYDO0NTxxd4qntcYKGl9CVtfhfjZrKf906fL4WU7Dt6kytwN+z2p kS0A/vLgooxwyo0pnHwBqUR89GMCVDG2mT6DCIe+n2XRuDb1pYv9Fv0UxLm4E0o4AHSP Swfw== X-Gm-Message-State: AMke39nFQ0AOvdNzZsSCoad8AuYHUreooz3pXwH8bnZEQ4iCP+fb6hHg7hz8YSkewQoleg== X-Received: by 10.99.122.70 with SMTP id j6mr3414647pgn.89.1488654258120; Sat, 04 Mar 2017 11:04:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.27.71 with SMTP id l65ls11718861otl.41.gmail; Sat, 04 Mar 2017 11:04:16 -0800 (PST) X-Received: by 10.157.16.48 with SMTP id h45mr855735ote.10.1488654256928; Sat, 04 Mar 2017 11:04:16 -0800 (PST) In-Reply-To: X-Original-Sender: bengt.gustafsson@beamways.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:31422 Archived-At: ------=_Part_1214_2074571044.1488654255895 Content-Type: multipart/alternative; boundary="----=_Part_1215_1050567901.1488654255896" ------=_Part_1215_1050567901.1488654255896 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Den l=C3=B6rdag 4 mars 2017 kl. 17:14:18 UTC+1 skrev Oliver Kowalke: > > 2017-03-04 15:27 GMT+01:00 Bengt Gustafsson >: > >> >>> But I don't understand the need of data transfer at this low abstractio= n=20 >>>> level. After all, these are not threads, so there is no asynchronism t= o=20 >>>> think about.=20 >>>> >>> >>> P0534 is symmetric context switching, e.g. no coupling between caller= =20 >>> and callee as it is for generators/coroutines. >>> >> Exactly, that's why I asked why data transfer is needed _on the call/cc= =20 >> level_. I showed in my example that you can do data transfer on top of t= his=20 >> (at the generator level) with essentially no overhead. Giovanni pointed = out=20 >> that there may be the overhead of one register save/restore, and if this= =20 >> the performance gain you are after I think the price of a scary "void*"= =20 >> style interface (hidden behind an unsafe cast) is not worth it, and if t= he=20 >> access is to be tested the performance cost is definitely more than a=20 >> register save. >> > > I don't see your point - accessing a register if verry fast (1 CPU cycle = I=20 > guess). > The point is that if the feature does not have a large performance gain=20 compared to not having it, and if it does not avoid a complex=20 synchronization problem then why have it? I don't see that you have shown= =20 any major performance or synchronization gain. =20 > The data transfer as proposed in P0534 (and used for coroutine and fiber= =20 > implementation) does provide some kind of type-safety and no overhead if = no=20 > data are transferred. > While ideas in the direction of my Generator class offers compile time type= =20 safety and negligable overhead even if used! Not to mention a smaller API. =20 > =20 > >> And you don't know the identity of the continuation returned from=20 >> operator() in your case, what is the difference? The advantage of the in= =20 >> situ version is however obvious: You can't forget doing the assignment, = and=20 >> thereby leave the continuation object stale.=20 >> > > Suppose you have contoinuations c1, c2: > > c1 =3D callcc( foo); > c2 =3D callcc( bar); > > - in main() you resume c1: c1(); > This must mean that both foo and bar have transfered control back to main= =20 which in some later code calls c1(). > - c1 executes foo > continuing foo after its first context switch.=20 =20 =20 > - in foo you resume c2: c2() > ok, a bit odd but doable.=20 - c2 executes bar > continuing bar after its first context switch. =20 > - in bar you jump to main() > Unless you involve setjmp/longjmp I don't see a way fot this to happen...= =20 and those guys are not C++ safe anyway. What can happen is that foo gives= =20 bar access to its stored continuation and bar uses this to transfer control= =20 to main after its c1() call. And sure enough c1 now refers to bar after its second context switch. Yes= =20 this seems to be what you refer to. =20 > - 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=20 where other functions can reach them. Isn't this why we want to abstract=20 the continuation level into higher level abstractions which are easier to= =20 understand and where these types of oddities are easy to avoid. The only gain with the assignment is as a reminder of "next time this=20 continuation will continue executing somewhere else". But as that always=20 happens and you can not make something else happen by NOT doing the=20 assignment (except dropping a valuable asset) it seems rather error prone..= .. > =20 > >> >>> =20 >>> >>>> Also it would be interesting to know when this rather strange=20 >>>> functionality is useful. >>>> >>> >>> described in P0534: >>> you can invoke a new function after resuming the context that throws an= =20 >>> exception >>> >> =20 >> It is a bit hard to understsand this sentense.=20 >> > > context switching is a bit mind twisiting > =20 > >> Do you mean to resume a context after it has thrown an exception?=20 >> > > no - resume the context and then, if you are in the resumed context,=20 > create a new stack frame and execute your supplied function (that might= =20 > throw)=20 > OK, I understand what it does, my question was why this is useful.=20 > =20 > >> =20 >> >>> for instance you want abort and unwind the stack - instead to check for= =20 >>> abort each time the context is resumed you call invoke-ontop=20 >>> functionality to execute the throwing abort function only at the time p= oint=20 >>> you know you want to abort the continuation/context >>> >> I think you may be saying that once in a while one party injects code=20 >> that throws if an abort flag is set into another piece of code on the ot= her=20 >> side of the continuation.=20 >> > > yes > =20 > >> Or maybe you test the abort flag first and then injects a function which= =20 >> just throws an exception. Well that would be a way to get rid of the=20 >> continuation and properly unwind its stack, but didn't you have a specif= ic=20 >> way of doing that, such as desrtroying the continuation object? >> > > throwing an exeception was only one use case - infact if a suspended=20 > continuation has to be destroyed (instance goes out of scope) out of a de= ep=20 > callstack - the current implementation executes a function ontop of those= =20 > continuation that throws a speciall exception that unwinds the stakc of t= he=20 > continuation and jumps back to the caller. > Yes, that is how I understood it. This is what would happen if you forget= =20 to assign the returned continuation to your variable, I assume ;-) So the only use case for invoke_on_top() that you have produced is in fact= =20 equivalent to destroying the continuation object. Given that you can't=20 access data in underlying stack frames I fail to see a difference between= =20 these two: continuation c; fun() c() and c.invoke_on_top(fun); Well, there may be some difference if fun throws, but isn't it unlikely=20 that the code dormant in c would have suitable catch clauses for throws in= =20 an unrelated function fun. Ok, maybe you only see this as a method of throwing an exception in the=20 other stack, if so maybe it would be better to have an explicit mechanism= =20 for this: template continuation::throw_in(Args...); This just swaps the stacks and then executes `throw EX(args...)` The advantage of this approach is that it is obvious what it does and it=20 does not invite to inject arbitrary function calls (which may throw=20 exceptions without catching them) onto some other stack not prepared for=20 this., I would have thought that the main use would be to allow a pool of fibers= =20 to be used for executing arbitrary code. The main reason for not doing new= =20 callcc() calls each time would be to avoid having to allocate stacks each= =20 time. If this is the use case it seems that the stack rather than the=20 continuation is the object to preserve and pool. It may be that this is the= =20 functionality Nicol was asking for. =20 > =20 > --=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/113327fb-b26a-421e-9b07-9a2045c4178f%40isocpp.or= g. ------=_Part_1215_1050567901.1488654255896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den l=C3=B6rdag 4 mars 2017 kl. 17:14:18 UTC+1 skr= ev Oliver Kowalke:
2017-03-04 15:27 GMT+01:00 Bengt Gusta= fsson <bengt.gu...@beamways.com>:

But I don't understand the need of data transfer at this= low abstraction level. After all, these are not threads, so there is no as= ynchronism to think about.

P0534 is symmetric context switching, e.g. no coupling between caller and= callee as it is for generators/coroutines.
=
Exactly, that's why I asked why dat= a transfer is needed _on the call/cc level_. I showed in my example that yo= u can do data transfer on top of this (at the generator level) with essenti= ally no overhead. Giovanni pointed out that there may be the overhead of on= e register save/restore, and if this the performance gain you are after I t= hink the price of a scary "void*" style interface (hidden behind = an unsafe cast) is not worth it, and if the access is to be tested the perf= ormance cost is definitely more than a register save.

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 gai= n compared to not having it, and if it does not avoid a complex synchroniza= tion problem then why have it? I don't see that you have shown any majo= r performance or synchronization gain.

=C2=A0
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.
<= /div>
While ideas in the direction of my Generator class o= ffers compile time type safety and negligable overhead even if used! Not to= mention a smaller API.
=C2=A0
=C2= =A0
=C2=A0And you don't know the identity of the continuation r= eturned from operator() in your case, what is the difference? The advantage= of the in situ version is however obvious: You can't forget doing the = assignment, and thereby leave the continuation object stale.=C2=A0

Suppose you have contoinuations = c1, c2:

c1 =3D callcc( foo);
c2 =3D callcc( bar);

- in main() you resume c1: c1();
=
This must mean that both foo and bar have transfere= d control back to main which in some later code calls c1().
- c1 executes foo
continuing foo after its first context switch.=C2=A0
=C2=A0
=C2=A0
- in foo you resume c= 2: c2()
ok, a bit odd but doab= le.=C2=A0

=
- c2 execu= tes bar
continuing bar after i= ts first context switch.
=C2=A0
- in bar you jump to main()
=
Unless you involve setjmp/longjmp I don't see a way fot this to ha= ppen... and those guys are not C++ safe anyway. 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.
And sure enough c1 now refer= s to bar after its second context switch. Yes this seems to be what you ref= er to.
=C2=A0
<= div dir=3D"ltr">
- that mean= s 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 varia= bles where other functions can reach them. Isn't this why we want to ab= stract the continuation level into higher level abstractions which are easi= er to understand and where these types of
oddities are easy to av= oid.

The only gain with the assignment is as a rem= inder of "next time this continuation will continue executing somewher= e else". But as that always happens and you can not make something els= e happen by NOT doing the assignment (except dropping a valuable asset) it = seems rather error prone...

=C2=A0
<= div dir=3D"ltr">

=C2=A0
Also it would be interesting to know when this rather strange fu= nctionality is useful.

describe= d in P0534:
you can invoke a new function after resuming the = context that throws an exception
=C2=A0
It is a bit hard to understsand this sentense. <= /div>

context switching is a bit mind= twisiting
=C2=A0
Do you mean to resume a context after it = has thrown an exception?

no - = resume the context and then, if you are in the resumed context, create a ne= w stack frame and execute your supplied function (that might throw)
OK, I understand what it does, my qu= estion was why this is useful.=C2=A0
=C2=A0
=C2=A0
for in= stance you want abort and unwind the stack - instead to check = for abort each time the context is resumed you call invoke-ontop functionality to execute the throwing abort function only at the time po= int you know you want to abort the continuation/context
I think you may be saying that once in a w= hile one party injects code that throws if an abort flag is set into anothe= r piece of code on the other side of the continuation.

yes
=C2=A0
Or maybe you test the a= bort flag first and then injects a function which just throws an exception.= Well that would be a way to get rid of the continuation and properly unwin= d its stack, but didn't you have a specific way of doing that, such as = desrtroying the continuation object?

throwing an exeception was only one use case - infact if a suspended = continuation has to be destroyed (instance goes out of scope) out of a deep= callstack - the current implementation executes a function ontop of those = continuation that throws a speciall exception that unwinds the stakc of the= continuation and jumps back to the caller.
Yes, that is how I understood it. This is what would happen i= f you forget to assign the returned continuation to your variable, I assume= ;-)

So the only use case for invoke_on_top() that= you have produced is in fact equivalent to destroying the continuation obj= ect. Given that you can't access data in underlying stack frames I fail= to see a difference between these two:

continuati= on c;

fun()
c()

and
c.invoke_on_top(fun);

Well, there m= ay be some difference if fun throws, but isn't it unlikely that the cod= e dormant in c would have suitable catch clauses for throws in an unrelated= function fun.

Ok, maybe you only see this as a me= thod of throwing an exception in the other stack, if so maybe it would be b= etter to have an explicit mechanism for this:

temp= late<typename EX, typename.... Args> continuation::throw_in(Args...);=

This just swaps the stacks and then executes `thr= ow EX(args...)`

The advantage of this approach is = that it is obvious what it does and it does not invite to inject arbitrary = function calls (which may throw exceptions without catching them) onto some= other stack not prepared for this.,

I would have = thought that the main use would be to allow a pool of fibers to be used for= executing arbitrary code. The main reason for not doing new callcc() calls= each time would be to avoid having to allocate stacks each time. If this i= s the use case it seems that the stack rather than the continuation is the = object to preserve and pool. It may be that this is the functionality Nicol= was asking for.
=C2=A0
= =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/113327fb-b26a-421e-9b07-9a2045c4178f= %40isocpp.org.
------=_Part_1215_1050567901.1488654255896-- ------=_Part_1214_2074571044.1488654255895-- .