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 23:48:47 -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="40855"; 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 Tue Apr 18 05:49:59 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 1pocLu-000AMi-Fs for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Apr 2023 05:49:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pocKy-000709-IZ; Mon, 17 Apr 2023 23:49:01 -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 1pocKs-0006zs-TI for emacs-devel@gnu.org; Mon, 17 Apr 2023 23:48:56 -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 1pocKq-0004Ny-U7 for emacs-devel@gnu.org; Mon, 17 Apr 2023 23:48:54 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7DAC380AD9; Mon, 17 Apr 2023 23:48:50 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0F6498017D; Mon, 17 Apr 2023 23:48:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1681789729; bh=XaBRKbNLt8kalk8jZnZHJYGv4+MR26P2mtKt6uPUK7Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ox5iXqo32oTBUEFu52ao5sW4CHa0bf68kD22HV+xmyEm1/oM6Ni+kTXK3NsrrsjNs BHNkj+T5vJrP7GFb37zV2cnDHrXPk9vb58nz5kNIH8LmGJZh0n9ebOOvyzpB4UF3TC wkgYr+gM18v3wM4pOTdrqamfFSHKet2ia2VcIFQchpZGerNLazIQnzgRcLp2WGQLeT ovi2cVc5F/XzbkQQJcZVYVRNdSkpKAphyZdUpudrN/5cC9W6SU64y7Uz9+0h1fxRZl K97hvsB5b/YIszlHsEJVYOwKRPU1SvZkzXv+Taq03qDur171aafcUpujfTL64br6I1 JkNGxnv2SRU/A== Original-Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C5D3912030C; Mon, 17 Apr 2023 23:48:48 -0400 (EDT) In-Reply-To: (Lynn Winebarger's message of "Mon, 17 Apr 2023 22:56:13 -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:305396 Archived-At: > I wrote that incorrectly - I meant that primitive operations would add > a continuation to the future and return a future for their result. > Basically, a computation would never block, it would just build > continuation trees (in the form of futures) and return to the > top-level. Although that assumes the system would be able to allocate > those futures without blocking for GC work. I think this would end up being extremely inefficient, since for every tiny operation you'd end up creating a future, linked to the previous computation (basically a sort of fine-grained dataflow graph). I'm sure in theory it can be made tolerably efficient, but it'd need a very different implementation strategy than what we have now. Furthermore I expect it would lead to surprising semantics when used with side-effecting operations. IOW you can probably create a usable system that uses this approach, but with a different language and a different implementation :-) `futur.el` instead forces the programmer to be somewhat explicit about the concurrency points, so they have *some* control over efficiency and interaction with side-effects. > At some point in this thread you stated you weren't sure what the > right semantics are in terms of the information to save, etc. I posed > this implicit semantics as a way to think about what "the right thing" > would be. Would all operations preserve the same (lisp) machine > state, or would it differ depending on the nature of the operator? [ > is the kind of question it might be useful to work out in this thought > experiment ] I can't imagine it working sanely if the kind of state that's saved depends on the operation: the saved-state is basically private to the continuation, so it might make sense to do it differently depending on the continuation (tho even that would introduce a lot of complexity), but not depending on the operation. The coders will need to know what is saved and what isn't, so the more complex this rule is, the harder it is to learn to use this tool correctly. > The way you've defined future-let, the variable being bound is a > future because you are constructing it as one, but it is still a > normal variable. > > What if, instead, we define a "futur-abstraction" (lambda/futur (v) > body ...) in which v is treated as a future by default, and a > future-conditional form (if-available v ready-expr not-ready-expr) > with the obvious meaning. If v appears as the argument to a > lambda/future function object it will be passed as is. Otherwise, the > reference to v would be rewritten as (futur-wait v). Some syntactic > sugar (futur-escape v) => (if-available v v) could be used to pass the > future to arbitrary functions. Seems complex, and I'm not sure it would buy you anything in practice. > Otherwise, I'm not sure what the syntax really buys you. Not very much. To some extent it simply helps reduce the indentation due to nesting. > It would be easier if elisp threads were orthogonal to system threads, > so that any elisp thread could be run on any available system thread. Currently, only one thread can run ELisp at a time. Whether that's implemented using several system threads or not is largely an internal detail. > Multiprocessing could be done by creating multiple lisp VMs in a > process (i.e. lisp VM orthogonal to a physical core), Yes, "could". Other than approaches like `async.el` we don't really know how to implement that, sadly. [ Many years ago I proposed to rely on `fork`, but it so happens that it's not really an option for the w32 builds :-( ] > each with their own heap and globals in addition to some shared heap > with well-defined synchronization. The "global interpreter lock" > would become a "lisp machine lock", with (non-preemptive, one-shot > continuation type) elisp threads being local to the machine. > That seems to me the simplest way to coherently extend the lisp > semantics to multi-processing. The display would presumably have to > exist in the shared space for anything interesting to happen in terms > of editing, but buffers could be local to a particular lisp machine. It's not too hard to come up with a design that makes sense, indeed, the problem is to actually do the work of bringing the current code to that design. Stefan