220 31418 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 17:13:54 +0100 Lines: 217 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f403045c60fa1503230549e9f4ab X-Trace: blaine.gmane.org 1488644060 15353 195.159.176.226 (4 Mar 2017 16:14:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 16:14:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCLZHP5J7MHRBV6P5PCQKGQE2XZEHMY@isocpp.org Sat Mar 04 17:14:14 2017 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 1ckCJw-00033e-6z for gclcip-std-proposals@m.gmane.org; Sat, 04 Mar 2017 17:14:12 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id u81sf49069283uau.6 for ; Sat, 04 Mar 2017 08:14:18 -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=bN0ovnK7XERsCgqYHeBnIKEWzJevQjOcO8EApGOF8ss=; b=ipBN5S3CuAG/CPn9KhnIb7eTJnA4D+dstXqYTO9DtCPF57ADOIJpJeI2mp8QHjSb6J Y19ag+MNSOTQnnYJefPRKZpkiXHtr5ahDp8j7MnGDBblZaXHYEQFsRBHLTOzQr7wxKHd JKkjrG4DHs4QeTSSP3O4dfhQff31C1YYuKeynFPu/2FhdpZ2gnJk+5RSVa14F+9YfOC2 Q9k1HvSmNd63TpDyygss2W0WGYM2oXn/jhPe48HBNRgdt3X5mhw3myf4SbCYKRLvzMyH QRUxS5yeSZU8gFeffbmacrqDcLhkbSjRDCw4BzMkOj6oGXuhrXrJH0h4RRxza3x5QMxz eNHQ== 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=bN0ovnK7XERsCgqYHeBnIKEWzJevQjOcO8EApGOF8ss=; b=J1yai5nYTXo0zpfVqxwevQi1Ny6x7OMvcrj8sVjJ6PiDrHFHse1wtS0X7Y9LMJxK7O XQTcAXGVCpw83/iH1F4bf9rT5ExkpP7+MQjYSbkNEff7wgSDIbUJIcX88KExlfLFmkkO /DrVqiEZozJkxuvXP7BrREX+WYEKTaznwqLIdB9zUs8tvAz24NbtspqbAGWeUIXH1Tk8 d2VXiQ/+tpNOcEpPEWW2E9YON8YZd5rpNS56VlMHZ1PJdH6BhTUw9D+ZyWts2payh+sA z6E5LGDXuD2XEHnATAf6Fs2gP6DLUjef9S0IiKo1a83pOtr1ouNdonQGmb7Ael0DIhzF H2HA== X-Gm-Message-State: AMke39ncbuiYjed4b0+ahtuTMgf4yeJobXuV/Ylu8n12dQgGIeH0maWxDu/MYxEyrk8GMA== X-Received: by 10.176.7.194 with SMTP id d2mr1765065uaf.17.1488644057903; Sat, 04 Mar 2017 08:14:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.37.197 with SMTP id l188ls3511336iol.14.gmail; Sat, 04 Mar 2017 08:14:15 -0800 (PST) X-Received: by 10.84.238.199 with SMTP id l7mr12792304pln.90.1488644055226; Sat, 04 Mar 2017 08:14:15 -0800 (PST) Original-Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com. [2607:f8b0:400e:c00::22f]) by mx.google.com with ESMTPS id j61si13834656plb.86.2017.03.04.08.14.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 08:14:15 -0800 (PST) Received-SPF: pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:400e:c00::22f as permitted sender) client-ip=2607:f8b0:400e:c00::22f; Original-Received: by mail-pf0-x22f.google.com with SMTP id v190so6317451pfb.1 for ; Sat, 04 Mar 2017 08:14:15 -0800 (PST) X-Received: by 10.99.122.13 with SMTP id v13mr10302122pgc.31.1488644054776; Sat, 04 Mar 2017 08:14:14 -0800 (PST) Original-Received: by 10.100.182.227 with HTTP; Sat, 4 Mar 2017 08:13:54 -0800 (PST) In-Reply-To: <33bda80d-c83a-4cb9-a67f-5c7b2658e060@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::22f 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:31418 Archived-At: --f403045c60fa1503230549e9f4ab Content-Type: text/plain; charset=UTF-8 2017-03-04 15:27 GMT+01:00 Bengt Gustafsson : > >> 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 asynchronism 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 data transfer is needed _on the call/cc > level_. I showed in my example that you can do data transfer on top of this > (at the generator level) with essentially no overhead. Giovanni pointed out > that there may be the overhead of one register save/restore, and if this > the performance gain you are after I think 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 performance 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 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. > And you don't know the identity of the continuation returned 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. > Suppose you have contoinuations c1, c2: c1 = callcc( foo); c2 = callcc( bar); - in main() you resume c1: c1(); - c1 executes foo - in foo you resume c2: c2() - c2 executes bar - in bar you jump to main() - that means you return from c1() in main() - if you call c1() in main() you do resume bar() instead of foo() > >> >> >>> Also it would be interesting to know when this rather strange >>> functionality is useful. >>> >> >> described in P0534: >> you can invoke a new function after resuming the context that throws an >> exception >> > > It is a bit hard to understsand this sentense. > context switching is a bit mind twisiting > 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 new stack frame and execute your supplied function (that might throw) > > >> for instance 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 point >> you know you want to abort the continuation/context >> > I think you may be saying that once in a while one party injects code that > throws if an abort flag is set into another piece of code on the other side > of the continuation. > yes > Or maybe you test the abort 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 unwind 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. -- 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_jk4zFYjr4nrvFzhN6RY9XrfSipVPEwPfSRbY8hMQJzg%40mail.gmail.com. --f403045c60fa1503230549e9f4ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017= -03-04 15:27 GMT+01:00 Bengt Gustafsson <bengt.gustafsson@beam= ways.com>:

But I don= 9;t understand the need of data transfer at this low abstraction level. Aft= er all, these are not threads, so there is no asynchronism to think about. =

P0534 is symmetric contex= t switching, e.g. no coupling between caller and callee as it = is for generators/coroutines.
Exactly, that's why I asked why data transfer is needed _on th= e call/cc level_. I showed in my example that you can do data transfer on t= op of this (at the generator level) with essentially no overhead. Giovanni = pointed out that there may be the overhead of one register save/restore, an= d if this the performance gain you are after I think the price of a scary &= quot;void*" style interface (hidden behind an unsafe cast) is not wort= h it, and if the access is to be tested the performance cost is definitely = more than a register save.

I do= n't see your point - accessing a register if verry fast (1 CPU cycle I = guess).
The data transfer as proposed in P0534 (and used for = coroutine and fiber implementation) does provide some kind of type-safety a= nd no overhead if no data are transferred.
=C2=A0
=C2=A0And you don't know the identity of the continuation ret= urned from operator() in your case, what is the difference? The advantage o= f the in situ version is however obvious: You can't forget doing the as= signment, and thereby leave the continuation object stale.=C2=A0

Suppose you have contoinuations c1= , c2:

c1 =3D callcc( foo);
c2 =3D callcc( bar);
<= div>
- in main() you resume c1: c1();
- c1 executes foo
- in foo you resume c2: c2()
- c2 executes bar
- in bar you jump to main()
- that means you retu= rn from c1() in main()
- if you call c1() in main() you do re= sume bar() instead of foo()

=C2=A0

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

described in P0534:
you can invoke a new function after resuming the context that throws an e= xception
=C2=A0
It is a bit hard to understsand this sentense. =

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 t= hen, if you are in the resumed context, create a new stack frame and execut= e your supplied function (that might throw)
=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.
=C2=A0
<= /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.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_jk4zF= Yjr4nrvFzhN6RY9XrfSipVPEwPfSRbY8hMQJzg%40mail.gmail.com.
--f403045c60fa1503230549e9f4ab-- .