220 31311 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: Thu, 2 Mar 2017 13:29:45 +0100 Lines: 211 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f403045e61fcca0a1c0549be96cd X-Trace: blaine.gmane.org 1488458122 7945 195.159.176.226 (2 Mar 2017 12:35:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Mar 2017 12:35:22 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCLZHP5J7MHRBB5D4DCQKGQEQAA3WQA@isocpp.org Thu Mar 02 13:35:16 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjPww-0001aF-MN for gclcip-std-proposals@m.gmane.org; Thu, 02 Mar 2017 13:35:14 +0100 Original-Received: by mail-yw0-f198.google.com with SMTP id 2sf118555954ywn.1 for ; Thu, 02 Mar 2017 04:35:20 -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=iof06WlEfEb75kynZYbuCL4vucyVUGTkTHo7Fl+Lw1A=; b=mtEViiuUjbKYUiaHcPG2PY/HVDOq3Ywiab/lqK2qg+7DpRoK2PH+8lbYHFPF/DtoJp pprLzgdl3W/9sZ+XahQkBDFyNNHFlxIhAAYpkXSKTfji7d2wlZsMig2Z1QeyCjmqFDgb LuWYN6wvnhPrLysqIyV8Shn8URTCu2bdYYsMlkoctK+12cwNbdIi2DH+lkjgxakasbi6 8jmzt8pUXBcvy3c3p/dY6BsYi5ArUJ3BLoKhafujTJl7oifnW78M4RCUIzCV5BHmEjac +BvU0aJGMUag+LOXsXQuQO9KiOJKwJdqDRv1cqdRCIGWqQlymXLm+YwZwb9/Qt+d4eIv gGog== 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=iof06WlEfEb75kynZYbuCL4vucyVUGTkTHo7Fl+Lw1A=; b=nCbpD9Kp6P1sEFTpnd9fFYebKPhrk7+RYHJOXDM/jgFgS/WQS8g8LgSLKfdNPTpn6t /xlXfu8KGgebh+8r8qOXgUVnRAxCt9Vp65msdZpaOXrz0B1hZo4ArBhxwJS4I+mNp4rF kPWK5Fjk+5Kl4nRTa/QprMgdUvSUmMHSHammffTV8foy9R8X5YS0CjzdrEvJRdGGefdH 7459Owq26jDaFhQHzcSOKB+Z5X53JkPAL5NYz/JWak4hVOzLC8Bm1g+FmQmqRusLU3sj G0721tzxeN0KMs5oQZcnzJf08zuZamCrsIqK4NOdORGyR4pW59eFh5jvyENyjp8eLovU j6Eg== X-Gm-Message-State: AMke39mHKs51gIelfwnqF7OL6FsH41f1rrFacdTMCXQ8xJzpoo3L8YwT2z/sBYjwW6HsnQ== X-Received: by 10.129.74.65 with SMTP id x62mr2646593ywa.65.1488458120270; Thu, 02 Mar 2017 04:35:20 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.11.3 with SMTP id a3ls4006293ota.23.gmail; Thu, 02 Mar 2017 04:35:19 -0800 (PST) X-Received: by 10.37.244.11 with SMTP id q11mr4428958ybd.26.1488458119304; Thu, 02 Mar 2017 04:35:19 -0800 (PST) Original-Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com. [2607:f8b0:4002:c05::229]) by mx.google.com with ESMTPS id f3si236149ywk.177.2017.03.02.04.35.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Mar 2017 04:35:19 -0800 (PST) Received-SPF: pass (google.com: domain of oliver.kowalke@gmail.com designates 2607:f8b0:4002:c05::229 as permitted sender) client-ip=2607:f8b0:4002:c05::229; Original-Received: by mail-yw0-x229.google.com with SMTP id d1so54890321ywd.2 for ; Thu, 02 Mar 2017 04:35:19 -0800 (PST) X-Received: by 10.129.141.6 with SMTP id d6mr4434160ywg.36.1488457805985; Thu, 02 Mar 2017 04:30:05 -0800 (PST) Original-Received: by 10.129.173.21 with HTTP; Thu, 2 Mar 2017 04:29:45 -0800 (PST) In-Reply-To: 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:4002:c05::229 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:31311 Archived-At: --f403045e61fcca0a1c0549be96cd Content-Type: text/plain; charset=UTF-8 2017-03-02 10:43 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 > 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(). > 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 > 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 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 > 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 -- 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-Pd3iR%2BxBeqDc4AZ_BpPFJRJw5grusofJaY8UuUnvEcA%40mail.gmail.com. --f403045e61fcca0a1c0549be96cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017= -03-02 10:43 GMT+01:00 Bengt Gustafsson <bengt.gustafsson@beamways.com>:
But I don't unde= rstand 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

= =C2=A0
When I wrote the code for generator.h I also saw that the pattern = `mContinuation =3D mContinuation()` seems to be mandatory. If you forget th= e assignment you loose the ability to continue the next time. While there m= ay be cases where you want to assign the continuation returned from operato= r() to some other std::continuation object, wouldn't it be more appropr= iate to make simple things simple by letting operator() return void and aut= omatically update its `this` to the new state before returning and then app= lications which really do need to move the continuation object elsewhere ca= n 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 continuati= on 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 fro= m continuation::operator().

=C2=A0
A comment on the invoke_on_top_t functionality. Why add a special tag typ= e just to be able to overload operator() to do another task when there is t= he possibility to add a regular method: std::continuation::invoke_on_t= op(args...).

both is possible := because apply-operator does the context switch I'd like to use the sam= e operator to do the context switch + invoking an function on the resumed c= ontext

=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 exception
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 th= e throwing abort function only at the time point you know you want to abort= the continuation/context

=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 busy - so it didn't got the highest prio/keep in mind I do = it at my freetim= e

--
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-Pd3= iR%2BxBeqDc4AZ_BpPFJRJw5grusofJaY8UuUnvEcA%40mail.gmail.com.
--f403045e61fcca0a1c0549be96cd-- .