From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: continuation passing in Emacs vs. JUST-THIS-ONE Date: Sun, 16 Apr 2023 23:46:30 -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; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18753"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tomas Hlavaty , Jim Porter , Karthik Chikmagalur , Thomas Koch , "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 17 05:46:41 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 1poFpA-0004hS-Vc for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Apr 2023 05:46:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poFoY-0004KV-SJ; Sun, 16 Apr 2023 23:46:02 -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 1poFoX-0004KL-4R for emacs-devel@gnu.org; Sun, 16 Apr 2023 23:46:01 -0400 Original-Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1poFoV-0006Zy-AG for emacs-devel@gnu.org; Sun, 16 Apr 2023 23:46:00 -0400 Original-Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1a50cb65c92so17224805ad.0 for ; Sun, 16 Apr 2023 20:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681703157; x=1684295157; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=depKxNcqjZGxP0iVDNwnlhc6yOBe6u2NRAKQrVAvoxs=; b=TohfgJCPFiRjsRuD0fITsYhnjEYDtu2h3oL9raSltPPyrG1pvAy/R60RI6zjflyHRr jeF+zQUVNV0AsDBVX4/RBF4vTdeTz610E+kP+xo2oLb4M8gq1lSM7Lc8FWijEckL9kb3 meA3PfZWMG4ZR37Y/c2iCzZ2hcj1Rlf2bM33WIIKpFUiLWlQVQ4uvCgRmIdFF2+WbdvJ s2UrkKP4MG2aAdyQALDyVg8AOO5LEdzSwh93H78gSYSzo9nlK4fRQsIJaXyxKeFmg8TR h1WRiDbKImT32OikA59Df1V8zfBJnIgWrW5F+S1dvHNXZbE2k6bvszpIW9sRjuGhoryk l5qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681703157; x=1684295157; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=depKxNcqjZGxP0iVDNwnlhc6yOBe6u2NRAKQrVAvoxs=; b=I6ysSDC+le9Q4KouGJX+WMBCUWz20+dytM2OkpnIuadY5/I8yTrdj762aVv6UQrUiL oGS1Gp7/PpfG7GcutV86DMoAcMFW7wKpRoaREBTBIUjfHV0JrKyvzwptIwbFQeVQOXV/ LQEKVYWsFOJWL1HlFcZMzstO2vjErntwgc0ftd2SrHywYd81Bo++frNwUrQm08GmBVVQ H5OZqsyKBfRUQiK4L1L7WONKSdNCk2egBzQF/pFMRkP9SyC3ilJz7QKSfh/P/7+/9dQn s6edEZXTv2n5t+cGqKxLTHCcoOpAoKdhJmC91mGlhxKpLYpK5I8UGkuhG8q8AgRAmTyB kj6A== X-Gm-Message-State: AAQBX9dkmfX3XmWqS+6kP6N8eo1JFAOZf0QhbZ9iUSl8yz5Dctxn7ixn ye/MurXmrbtOU7rW/WzDhzg5OIvVpB2NOWTFxOk= X-Google-Smtp-Source: AKy350b8rFuqQHwM+9iK2Hsjzn1aFGzxu4z+/DYuN7fgIERuYty04pP4EBd1k4psrh5B3di/lCtwGD0FTaVWREcsM84= X-Received: by 2002:a05:6a00:2e09:b0:633:4fea:3d06 with SMTP id fc9-20020a056a002e0900b006334fea3d06mr6808050pfb.1.1681703157473; Sun, 16 Apr 2023 20:45:57 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::629; envelope-from=owinebar@gmail.com; helo=mail-pl1-x629.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:305359 Archived-At: On Wed, Mar 29, 2023 at 2:48=E2=80=AFPM Stefan Monnier wrote: > > >> Part of the issue is the management of `current-buffer`: should the > >> composition of futures with `futur-let*` save&restore > >> `current-buffer` to mimic more closely the behavior one would get > >> with plain old sequential execution? If so, should we do the same > >> with `point`? What about other such state? > > > > I do not think there is a good implicit solution. > > Either it would save too much state or too little, > > or save it the wrong way. > > Currently it doesn't save anything, which is "ideal" in terms of > efficiency, but sometimes leads to code that's more verbose than > I'd like. > > Someone suggested to save as much as threads do, but that's not > practical. > 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. 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. But making something like that work would require extensive reengineering of emacs internals. Looking at src/thread.c, it appears emacs threads are just thin layer over system threads with a global lock. An alternative would be to use a basic user-space cooperative threading implementation running on top of the system threads, which would simply run a trampoline to whatever user space thread was assigned to it. The user space threads would not be locked to any particular system thread, but go back to the queue of some emacs-owned scheduler after yielding control. Then if a primitive will block, it could switch to a fresh user-space thread running in the same user-space thread, put a future that references this new thread in the continuation for the original thread (which is placed back in emacs's scheduler queue), then give up the GIL before making the blocking call on the system thread. Then the emacs scheduler would choose some available system thread in its pool and dispatch the next user space continuation to it, eventually redispatching the original user-space thread. The whole sequence would play out again if a primitive operation blocked trying to read the value of the first future. I think that would provide the asynchronous but not concurrent semantics you're talking about. But it would be a lot of work. Lynn