From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Sat, 08 Jul 2023 17:26:24 +0300 Message-ID: <83a5w6cwdr.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <87a5w96x2o.fsf@localhost> <87jzvdjjp4.fsf@yahoo.com> <877crd6w53.fsf@localhost> <877crdjiwn.fsf@yahoo.com> <874jmh6v4s.fsf@localhost> <83y1jtgmbw.fsf@gnu.org> <87zg49xfke.fsf@localhost> <83sfa1gjns.fsf@gnu.org> <87r0plxbep.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.fsf@localhost> <83edljg8ub.fsf@gnu.org> <87o7knbxr7.fsf@localhost> <838rbrg4mg.fsf@gnu.org> <87ilavbvdr.fsf@localhost> <834jmffvhy.fsf@gnu.org> <878rbrbmwr.fsf@localhost> <83fs5zecpo.fsf@gnu.org> <87351zbi72.fsf@localhost> <83351yevde.fsf@gnu.org> <87cz12ad2w.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40738"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 08 16:27:31 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 1qI8uJ-000AMO-4q for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 16:27:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI8te-0000y0-RJ; Sat, 08 Jul 2023 10:26:50 -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 1qI8tc-0000xm-Qu for emacs-devel@gnu.org; Sat, 08 Jul 2023 10:26:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qI8tb-0000pI-Hg; Sat, 08 Jul 2023 10:26:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=AefYyAduAowJKZhgLJCMs9AQ0+gRLzvopzKUeqsLA1A=; b=pbm2wB/08ky3 iKoy7HagtBKoulOt3UguQo1RFRo9PR14lVSOzaT/KOK5ZTW9xtJkV86ehIhzyUSJ/XNOv7PSfjA6s /O3gHrnw/lk6v1Rd8Ganxgi/8ib6uhZR6jW3n7cVH22+FT/h1y3HeElD94lcJ+Ty/Th5FmOy8McyD Hmx2z7N/puF7tT7RgJkIGK0MfF/w/rwbCherh7htvFVBwZspGdWt0gKo3j4LnjgChbZJ8XAQxa2lQ sUpsbJ8ZaZ4x0H4qervR95Kb92azlhUR9NVi2p2VSxGrFtn4mRrI06zuTftR3s3njRpVLDL+U18CZ cDlGiTsJrnu0BAb950AxNw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qI8tA-0005Hs-JP; Sat, 08 Jul 2023 10:26:46 -0400 In-Reply-To: <87cz12ad2w.fsf@localhost> (message from Ihor Radchenko on Sat, 08 Jul 2023 10:53:59 +0000) 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:307615 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Sat, 08 Jul 2023 10:53:59 +0000 > > Ok. I tried to find an example myself by looking into `char-after'. > I can see CHAR_TO_BYTE->buf_charpos_to_bytepos->buf_next_char_len->BUF_BYTE_ADDRESS > and > FETCH_CHAR->FETCH_MULTIBYTE_CHAR->BYTE_POS_ADDR > > Will blocking GC for the duration of CHAR_TO_BYTE and buf_next_char_len > be a problem? Not by itself, no. But if you go this way, you eventually will lock everything all the time. > >> By transforming some of the global state variables into thread-local > >> variables. > > > > Which variables can safely and usefully be made thread-local? > > PT, ZV, BEGV Even that is not enough: you forgot the gap. > and the buffer-local variables that are represented by the > global C variables. That's a lot! > >> > I don't see how one can write a useful Lisp program with such > >> > restrictions. > >> > >> Pure, side-effect-free functions, for example. > > > > I don't see how this could be practically useful. > > For example, `org-element-interpret-data' converts Org mode AST to > string. Just now, I tried it using AST of one of my large Org buffers. > It took 150seconds to complete, while blocking Emacs. It isn't side-effect-free, though. I don't believe any useful Lisp program in Emacs can be side-effect-free, for the purposes of this discussion. Every single one of them accesses the global state and changes the global state. > > ... Besides the basic > > question of whether a useful Lisp program can be written in Emacs > > using only side-effect-free functions > > Yes. I mean... look at Haskell. There is no shortage of pure functional > libraries there. I cannot follow you there: I don't know Haskell. > > .. , there's the large body of > > subroutines and primitives any Lisp program uses to do its job, and > > how do you know which ones of them are side-effect-free or async-safe? > > (declare (pure t)) How many of these do we have, and can useful programs be written using only those? More importantly, when you call some function from simple.el, how do you know whether all of its subroutines and primitives are 'pure'? > > To take just one example which came up in recent discussions, look at > > string-pixel-width. Or even at string-width. > > Those must either be blocking or throw an error when called from async > thread. So we will always block. Which is what we already have with the Lisp threads. > Just to be clear, it is not a useful aim to make any arbitrary Elisp > code asynchronous. But if we can at least allow specially designed Elisp > to be asynchronous, it will already be a good breakthrough. No, it will not. It will be a fancy feature with little or no use. > And later, in future, if we can manage to reduce the amount global state > in Emacs, more Elisp code may be converted (or even work as is) > asynchronously. If we don't have a clear path towards that goal today, and don't even know whether such a path is possible, it will never happen. > Remember the lexical binding transition. I was not refused because some > Elisp code failed to work with it. Lexical binding is nothing compared to this.