From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: continuation passing in Emacs vs. JUST-THIS-ONE Date: Mon, 17 Apr 2023 15:50:40 -0400 Message-ID: References: <627090382.312345.1678539189382@office.mailbox.org> <87sfe7suog.fsf@gmail.com> <1c6fedae-10b4-5d97-5036-eaa736e1b816@gmail.com> <87mt4c6xju.fsf@logand.com> <87a6001xm0.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31878"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Tomas Hlavaty , Jim Porter , Karthik Chikmagalur , Thomas Koch , "emacs-devel@gnu.org" To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 17 21:51:47 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1poUt7-00082E-Hf for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Apr 2023 21:51:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poUsF-0007fA-S6; Mon, 17 Apr 2023 15:50:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poUsE-0007eh-MG for emacs-devel@gnu.org; Mon, 17 Apr 2023 15:50:50 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poUsC-0007Rt-N0 for emacs-devel@gnu.org; Mon, 17 Apr 2023 15:50:50 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C7C221000BE; Mon, 17 Apr 2023 15:50:46 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4641E10000A; Mon, 17 Apr 2023 15:50:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1681761041; bh=aM9/+aOmbTtfDDJU2RUc4yA6ksQ5YOktI7o5UwMRtq4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pEqexShgTDxWkVzpiDm3IwuBkoOMbjgNH4qSiMnefPi+L+PzPqBOFW/yRi+KXUVyr +/l0MfcJOklNzy6GDI6nqvg7K2mSzGJoCxtQ/prJTedJu0ieQHCgEQj1jPSEnxmI2A egbodqAFmJjvtg1L6pzvnkTl9g5BXEeodVLUi1wi8h9pFLSsoMP1nfEVcySKVpfL8Y iSvJMJ5Hyvvw7HQajUvzIs9Bo4xzO/DLHKl8XAe91a14mPIXnfAn7KsPRZPU4fJLRJ n2YWWB/SNMfwrJsqIuovIWiJEfBucAt8rikcq0vS9CfcoJ2C8HKQglK6NT598BOw7J zjrV0LixpSeFQ== Original-Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 04A651203D8; Mon, 17 Apr 2023 15:50:40 -0400 (EDT) In-Reply-To: (Lynn Winebarger's message of "Sun, 16 Apr 2023 23:46:30 -0400") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305386 Archived-At: > This whole thread seems to echo the difference between "stackless" and > "stackful" coroutines discussed in > https://nullprogram.com/blog/2019/03/10/ by the author of emacs-aio, > with generator-style rewriting corresponding to stackless and threads > to "stackful". So when you say "save as much as threads do", I'm not > clear if you're talking about rewriting code to essentially create a > heap allocated version of the same information that a thread has in > the form of its stack, or something more limited like some particular > set of special bindings. Indeed to "save as much as threads do" we'd have to essentially create a heap allocated version of the same info. [ I don't think that's what we want. ] > It seems to me what one would really like is for primitives that might > block to just return a future that's treated like any other value, > except that "futurep" would return true and primitive operations would > implicitly wait on the futures in their arguments. I think experience shows that doing that implicitly everywhere is not a good idea, because it makes it all too easy to accidentally block waiting for a future. Instead, you want to replace this "implicit" by a mechanism that is "as lightweight as possible" (so it's "almost implicit") and that makes it easy for the programmer to control whether the code should rather block for the future's result (e.g. `futur-wait`) or "delay itself" until after the future's completion (e.g. `future-let*`). > I think that would provide the asynchronous but not concurrent > semantics you're talking about. FWIW, I'm in favor of both more concurrency and more parallelism. My earlier remark was simply pointing out that the design of `futur.el` is not trying to make Emacs faster. Stefan