From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Sat, 08 Jul 2023 10:53:59 +0000 Message-ID: <87cz12ad2w.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8802"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 08 12:55:40 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 1qI5bI-00027e-Mi for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 12:55:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI5aI-0003QP-Sw; Sat, 08 Jul 2023 06:54:38 -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 1qI5aG-0003Pz-UQ for emacs-devel@gnu.org; Sat, 08 Jul 2023 06:54:37 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qI5a8-0002Tt-Vv for emacs-devel@gnu.org; Sat, 08 Jul 2023 06:54:36 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 56266240103 for ; Sat, 8 Jul 2023 12:54:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688813664; bh=iJkkiMWy8Edj6+vGtI76BQJsspPMA2taKNPlom6KPuw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=h8nm9A9/C5rBjxZ/1CvugWELnpys3x0Z8/yGBswQ8UtBN5XNVUREJLCIvgOB9kPTG dBak/MCyPpO3M8rke1/h9P149bcTfNbuYuAPUg5bAuxFKcvoTf48tuYEoyE2dP/Umt xGLN3a/vzVhUSH5JicWQ8zBQNLn1dG+f+AFWOY5UXGPLf3VE09ShRYBeGERHGHN+8G rLe7lyUV8aXqW0FP/vLp4sgFSn+Uc6wn2TTVGkJHrTjTlmfo4yvz3L4h/GoV/4hk4H 9tL4M1dTRm+jI4w+6Qt7EGrmwtxAXwFE0/bWZOcdi3bd5QA4o0MstY0tQqYDzwqPht MVigB5Gp+LpGw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QynFg3pYXz9rxP; Sat, 8 Jul 2023 12:54:15 +0200 (CEST) In-Reply-To: <83351yevde.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:307610 Archived-At: Eli Zaretskii writes: >> Can you please provide an example about "surprised"? Do you mean that >> buffer->pt will no longer be accurate? Something else? > > Not pt but the pointers to buffer text and the gap. Those determine > the address of a given buffer position in memory, and are used when a > Lisp program accesses buffer text in any way. GC can change them if > it decides to relocate buffer text or compact the gap. 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? GC between the calls to CHAR_TO_BYTE and buf_next_char_len, if it relocates buffer text/gap will not break anything, AFAIU. >> >> Then the question is: can the global state be reduced? >> > >> > By what measures? Please suggest something concrete here. >> >> 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, and the buffer-local variables that are represented by the global C variables. >> > 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. Or consider building large completion table. Or parsing HTML DOM string into sexp. Or JSON passed by LSP server. > ... 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. > .. , 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)) > 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. --- 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. 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. Remember the lexical binding transition. I was not refused because some Elisp code failed to work with it. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at