220 31417 <33bda80d-c83a-4cb9-a67f-5c7b2658e060@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 06:27:45 -0800 (PST) Lines: 314 Approved: news@gmane.org Message-ID: <33bda80d-c83a-4cb9-a67f-5c7b2658e060@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1140_1877694992.1488637665754" X-Trace: blaine.gmane.org 1488637674 32198 195.159.176.226 (4 Mar 2017 14:27:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 14:27:54 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRBYU55PCQKGQEHVRN2FA@isocpp.org Sat Mar 04 15:27:48 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f200.google.com ([74.125.82.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckAer-0007FK-O7 for gclcip-std-proposals@m.gmane.org; Sat, 04 Mar 2017 15:27:42 +0100 Original-Received: by mail-ot0-f200.google.com with SMTP id a12sf101292449ota.1 for ; Sat, 04 Mar 2017 06:27:48 -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=JZ8kHPvuMpU8GKKyxVuibviRN0Z3IeAFMUPhKMK4iFo=; b=aTpmHTkg7W3Wkw8cVbFo3Xqm879+ezq0d7vC5gPwbla2hJKuqdAfhQK1kMWvxJh4Xw CQxWO8qcsN+kLbowS5Y3G+xnU7TCuxzTnQuK2/+ENBvzvAlKqAnEJ6zBnwhOTaTfgymo 1IYcHim1oJPbJdzRwzz9dISlDMO5H24Rscv5SuaKT6A1NECyKNrDm3YIaUKIhJDL9C6k gIW0v7ttnMqXa1KO+Q/LFhgPI3xJh9DwhsKt75G3LlvtEqIu9TQSO4VOMrm+MVoLTahH +1MnxiKpO2zRKf7NBYIv5lL1N2T+lk8l0iL8Y3vik+X/NH53i9CwBWnLZXpPr8HWBmwL CXjw== 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=JZ8kHPvuMpU8GKKyxVuibviRN0Z3IeAFMUPhKMK4iFo=; b=Ff0DI2RbMWM4lP6fH0+pEifeW6MsGjMVrUevFq6XVwd0v0ZEBVlyJb3vIZmANITMfz XJDJ3f336eyTHIIE5BQrVVke3g2HTx378Mvc7UdI0GMMRQ5GJJEyckyPOtT2IbmB18jQ 3KpveCTy5tz4RPMalhJYo9l4r0qsffpdurfAWAYnwPZirPeAZWPvP9deICCNl3jp2gzH kUlBPAxqbXiZVlDSMEqyXog+kphxaSfLpNCbTvvvS5W5dcWRj1WV5/hs3Zb86VkeEPLx nI4BZSh3jg4hvSWINk5OQLIzK7WzGnqO75O/Z0t4i4lFzBsDQ4HARSsqpnWSUwdUetGb +wMg== X-Gm-Message-State: AMke39kzalOpK498Jq6w3yXMxTfZYlzgQEp0i86GXSxtgWVSYeYDo4AwZ0mcmNB+L9F3RA== X-Received: by 10.157.33.49 with SMTP id i46mr3198876otb.30.1488637667689; Sat, 04 Mar 2017 06:27:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.18.240 with SMTP id g103ls12216277otg.39.gmail; Sat, 04 Mar 2017 06:27:46 -0800 (PST) X-Received: by 10.157.67.140 with SMTP id t12mr777449ote.7.1488637666585; Sat, 04 Mar 2017 06:27:46 -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:31417 Archived-At: ------=_Part_1140_1877694992.1488637665754 Content-Type: multipart/alternative; boundary="----=_Part_1141_1224488377.1488637665754" ------=_Part_1141_1224488377.1488637665754 Content-Type: text/plain; charset=UTF-8 > > > 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. > > > > >> When I wrote the code for generator.h I also saw that the pattern >> `mContinuation = mContinuation()` seems to be mandatory. If you forget the >> assignment you loose the ability to continue the next time. While there may >> be cases where you want to assign the continuation returned from operator() >> to some other std::continuation object, wouldn't it be more appropriate to >> make simple things simple by letting operator() return void and >> automatically update its `this` to the new state before returning and then >> applications which really do need to move the continuation object elsewhere >> can do so afterwards. >> > > I've had several variations of callcc() implemented and I got into > troubles during the implementation of fibers (lightweight threads) using > such a kind of call/cc. > I would not consider to change the identity of a continuation while > invoking its operator() a good idea - you don't know to which context your > continuation points to (e.g. what it executes/does) after returning from > continuation::operator(). > 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. > > > >> A comment on the invoke_on_top_t functionality. Why add a special tag >> type just to be able to overload operator() to do another task when there >> is the possibility to add a regular method: >> std::continuation::invoke_on_top(args...). >> > > both is possible : because apply-operator does the context switch I'd like > to use the same operator to do the context switch + invoking an function on > the resumed context > I find this a very weak reason to go through the hoops of creating and using a specific tag class. > > > >> 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. Do you mean to resume a context after it has thrown an exception? If this is what you mean, there could be two cases: a) the exception was not caught. In this case the stack is completely unwound as if the function had returned, and what you are doing is only to reuse the stack memory, right? b) the exception was caught somewhere during unwindining and the continuation was invoked in a catch clause. Now the invoke_on_top injects some code to be run inside the catch. I still don't see what good this would do. Also, if there is a throw; below the continuation invokation things would get messy if the injected code throws (even if this exception is caught). > 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. 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? > > > >> An issue I stumbled upon during implementation was not being able to do >> callcc() on a method. I think an overload of callcc specifically for method >> pointers (in parallel with the std::function constructor set) will be >> needed. This is as the std::continuation&& parameter gets prepended to the >> args of callcc when calling the provided function. If the provided function >> is a std::function wrapping a method pointer its operator() will expect to >> get the 'this' of the object to call and instead it will get the >> std::continuation prepended by callcc! >> >> // Example: >> >> class MyClass { >> void fun(std::continuation&& cont); >> }; >> >> MyClass myObj; >> >> callcc(&MyClass::fun, myObj); // This is what you want to write, but >> callcc does not take method pointers. >> >> // So you may try this: >> >> callcc(std::function(&MyClass::fun), >> myObj); // Mismatched types as callcc gets the order wrong. >> >> // Instead you have to conjure up a lambda: >> >> callcc([&](std::continuation&& cont) { myObj.fun(std::move(cont); }); >> >> >> >> While the lambda solution works I think it is quite weak not to allow the >> first version. >> > > I'm too busy - so it didn't got the highest prio/keep in mind I do it at > my freetime > I do too, so we're in the same sitation there... In your next reply you again point at the _function_ based version of callcc, which is what caused my concern in the first place. Maybe you just pasted the wrong snippet? If not, here it is again: The problem is that as callcc prepends the continuation to the parameter list of the provided Fn there is a problem for a std::function encapsulating a method (which mandates a compatible object as its first invoktion parameter). -- 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/33bda80d-c83a-4cb9-a67f-5c7b2658e060%40isocpp.org. ------=_Part_1141_1224488377.1488637665754 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

But I don't understand the need of da= ta transfer at this low abstraction level. After all, these are not threads= , so there is no asynchronism to think about.
<= br>
P0534 is symmetric context switching, e.g. no coupling betwee= n caller and callee as it is for generators/coroutines.<= /span>
Exactly, that's why I a= sked why data transfer is needed _on the call/cc level_. I showed in my exa= mple 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 ov= erhead of one register save/restore, and if this the performance gain you a= re after I think the price of a scary "void*" style interface (hi= dden behind an unsafe cast) is not worth it, and if the access is to be tes= ted the performance cost is definitely more than a register save.
=C2=A0
=


=C2=A0
When I wro= te the code for generator.h I also saw that the pattern `mContinuation =3D = mContinuation()` seems to be mandatory. If you forget the assignment you lo= ose the ability to continue the next time. While there may be cases where y= ou want to assign the continuation returned from operator() to some other s= td::continuation object, wouldn't it be more appropriate to make simple= things simple by letting operator() return void and automatically update i= ts `this` to the new state before returning and then applications which rea= lly do need to move the continuation object elsewhere can do so afterwards.=

I've had several vari= ations of callcc() implemented and I got into troubles during = the implementation of fibers (lightweight threads) using such a kind of cal= l/cc.
I would not consider to change the identity of a contin= uation while invoking its operator() a good idea - you don't know to wh= ich context your continuation points to (e.g. what it executes/does) = after returning from continuation::operator().
=
And you don't know the identity of the continua= tion returned from operator() in your case, what is the difference? The adv= antage of the in situ version is however obvious: You can't forget doin= g the assignment, and thereby leave the continuation object stale.=C2=A0

=C2=A0
A = comment on the invoke_on_top_t functionality. Why add a special tag type ju= st to be able to overload operator() to do another task when there is the p= ossibility to add a regular method: std::continuation::invoke_on_top(a= rgs...).

both is possible : bec= ause apply-operator does the context switch I'd like to use the same op= erator to do the context switch + invoking an function on the resumed conte= xt

I find this= a very weak reason to go through the hoops of creating and using a specifi= c tag class.=C2=A0

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

described = in P0534:
you can invoke a new function after resuming the co= ntext that throws an exception
=C2=A0
It is a bit hard to understsand this sentense. Do you mea= n to resume a context after it has thrown an exception? If this is what you= mean, there could be two cases: a) the exception was not caught. In this c= ase the stack is completely unwound as if the function had returned, and wh= at you are doing is only to reuse the stack memory, right? b) the exception= was caught somewhere during unwindining and the continuation was invoked i= n a catch clause. Now the invoke_on_top injects some code to be run inside = the catch. I still don't see what good this would do. Also, if there is= a throw; below the continuation invokation things would get messy if the i= njected code throws (even if this exception is caught).
=C2=A0
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 thi= nk you may be saying that once in a while one party injects code that throw= s if an abort flag is set into another piece of code on the other side of t= he continuation. 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 ri= d of the continuation and properly unwind its stack, but didn't you hav= e a specific way of doing that, such as desrtroying the continuation object= ?
<= div class=3D"gmail_quote">

=C2=A0
An issue I stumbled = upon during implementation was not being able to do callcc() on a method. I= think an overload of callcc specifically for method pointers (in parallel = with the std::function constructor set) will be needed. This is as the std:= :continuation&& parameter gets prepended to the args of callcc when= calling the provided function. If the provided function is a std::function= wrapping a method pointer its operator() will expect to get the 'this&= #39; of the object to call and instead it will get the std::continuation pr= epended by callcc!

// Example:

class MyClass {=
=C2=A0 =C2=A0 void fun(std::continuation&& cont);
<= div>};

MyClass myObj;

cal= lcc(&MyClass::fun, myObj); =C2=A0 =C2=A0// This is what you want to wri= te, but callcc does not take method pointers.

// S= o you may try this:

callcc(std::function<void(<= wbr>MyClass&, std::continuation&&)>(&MyClass::fun),= myObj); =C2=A0 // Mismatched types as callcc gets the order wrong.

// Instead you have to conjure up a lambda:
callcc([&](std::continuation&& cont) { myObj.fun(st= d::move(cont); });


Whi= le the lambda solution works I think it is quite weak not to allow the firs= t version.

I'm too bus= y - so it didn't got the highest prio/keep in mind I do it= at my freetime
I do too, so we&#= 39;re in the same sitation there...

=C2=A0In your = next reply you again point at the _function_ based version of callcc, which= is what caused my concern in the first place. Maybe you just pasted the wr= ong snippet? If not, here it is again: The problem is that as callcc prepen= ds the continuation to the parameter list of the provided Fn there is a pro= blem for a std::function encapsulating a method (which mandates a compatibl= e object as its first invoktion parameter).
=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/33bda80d-c83a-4cb9-a67f-5c7b2658e060= %40isocpp.org.
------=_Part_1141_1224488377.1488637665754-- ------=_Part_1140_1877694992.1488637665754-- .