From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.devel Subject: Re: continuation passing in Emacs vs. JUST-THIS-ONE Date: Mon, 17 Apr 2023 23:19:38 -0700 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; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33497"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tomas Hlavaty , Karthik Chikmagalur , Thomas Koch , "emacs-devel@gnu.org" To: Stefan Monnier , Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 18 08:20:55 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 1poehy-0008Mi-Kt for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Apr 2023 08:20:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poeh6-0000Pg-Mg; Tue, 18 Apr 2023 02:20:00 -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 1poeh1-0000Ny-JH for emacs-devel@gnu.org; Tue, 18 Apr 2023 02:19:58 -0400 Original-Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1poegs-0007IV-7R for emacs-devel@gnu.org; Tue, 18 Apr 2023 02:19:55 -0400 Original-Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-63b7b54642cso835336b3a.0 for ; Mon, 17 Apr 2023 23:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681798779; x=1684390779; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=I6rhOvUOK0fGjZexKaGZFfWNvYKiQVMpa7rpRocNglU=; b=EYBRpCKMPm8JlEiz2qJ83TCS1UmpTJ1PRgdvFOnr6XTs6DtwF8KMDYGA57S1TgX/0+ NqJ4CrgUIaxBm90R6qiTyf5lJuE0NasjGSyyENUN97rYpouAejNGHDmeDMOKb5AzQVgF 7T7hB5jXbonT8kcfBDoFQEeL4bi43F6ZYeJl3X4mUj6hEWONrEnkVAmrtXqfJni7rkZe 78BFjjuSWUClv9vhh+BMDLg2s/f7NjOeHI/EQi75MpoF+QufZGz1w+F2SPocH3cFK8fk 3uCezWfD0aa8Illni7UkogHi0O6zkOJXyXfK/lh3ktdca6ZF5IDY3Y2J2tIog2RbIbZY mEKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681798779; x=1684390779; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=I6rhOvUOK0fGjZexKaGZFfWNvYKiQVMpa7rpRocNglU=; b=UtzEd5tiVVHJVKWNe0WPGtENcalymL3aKDSK480KLdk/B/iEfB0w1xbewj6bYctV2d gakD2VNJ7mtCGdDjuoGO2FC18c5snJYZNsDqI2hF4OmWnySqyJA0c49Hu+l57PZS1YGN F+PYKeyS4olzS9ayEBD5PTq54XmvLC+xGgU1BZ75oIIvyHtrueCG/QWkFjU/QhhNrxSU mlEuv9bBZyMj1Y4B5xeohjUjM7mzAT7MIf7VSR8iIcaLiLmsrrDOKlCVilsXKNKlNBDb 1eCQUQc8PWJn/2KTPSfGUYSLcyI8w34Nr/n8bTTzF1G+cEYe1DIfhW2oU2sZpw4XjeF4 ndqA== X-Gm-Message-State: AAQBX9d/bEmaPI5Ujxh5mII8Mp40rmFTXRFT7WdDbPMIartKf+ubdIya 0hM752o+2fEynU1vPHmbOt4= X-Google-Smtp-Source: AKy350ba4aUTgI8hk8jI4IjZeK+xOIhoYDFYEVrqtZhic5g7vesHqJ3fOD052c+DjBbAs+GHgAfWCQ== X-Received: by 2002:a17:902:d709:b0:1a6:494c:f723 with SMTP id w9-20020a170902d70900b001a6494cf723mr787639ply.54.1681798779161; Mon, 17 Apr 2023 23:19:39 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id w22-20020a170902a71600b001a520f9071dsm8731610plq.7.2023.04.17.23.19.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Apr 2023 23:19:38 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::42b; envelope-from=jporterbugs@gmail.com; helo=mail-pf1-x42b.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:305399 Archived-At: On 4/17/2023 12:50 PM, Stefan Monnier wrote: >> 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. ] I think this subthread is about two different aspects, which is probably due in part to me not distinguishing the two enough initially; one of the reasons I'd find it useful to "save as much as threads do" is so that there could be a path towards packaging tasks up to run on another thread, and for them to eventually have enough context that we could run multiple packaged tasks *concurrently*. That's separate from a more-general asynchronous programming library (though they would likely interact with one another). Javascript might be a useful analogue here, since it too was originally single-threaded with an event loop, and more concurrency features were added in later. Similarly to "modern" JS, we could have async/await constructs that (primarily) work on the main thread, plus something similar to web workers, which operate as mostly-independent threads that you can communicate with via messages.