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: Sun, 09 Jul 2023 09:36:15 +0000 Message-ID: <87pm518m0g.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <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> <83a5w6cwdr.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="35231"; 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 Sun Jul 09 11:36:54 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 1qIQqa-0008yS-NF for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 11:36:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIQpy-0001G0-W9; Sun, 09 Jul 2023 05:36:15 -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 1qIQpx-0001Fn-Te for emacs-devel@gnu.org; Sun, 09 Jul 2023 05:36:13 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIQpv-0002SX-Fe for emacs-devel@gnu.org; Sun, 09 Jul 2023 05:36:13 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 622DB240029 for ; Sun, 9 Jul 2023 11:36:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688895369; bh=3L8C6+CU8gj1YTXRja6x0u2qk5TX+PbBZMy2yzqLS0c=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=GKwICXLsMx1tiWikndD2W7Xp92/Ugo2cVkGTRVOvJUgH5UpNKPwGBpgu5tJh5ZuO7 uB8nspguJ+C8WkSZhEaAODMALTZKaeOYo7HspvuoWJJ8TBAlVvqn3P/g6sGFpUVjW+ pjPepasfzZi7tnWSLdW+cMkLbf6tLiah2mOnXMs9sUCsxzgHEFI5cDFFC2RMdV2F1c Lrz5PlSkukVyZdaD5IkSOKzwUI0jlhJKC6Ip1UPiiKX6pw+j2YqJqbZQ8VMX/xgeL7 u5bK+/41c8wJw9rk6U4La2Iimv0v34TO0TEgYcmIeAuHz77HiPqoCFxBuYJfDUcr9u /JEA7VHTAlXRQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QzMT43pwXz9rxP; Sun, 9 Jul 2023 11:36:08 +0200 (CEST) In-Reply-To: <83a5w6cwdr.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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:307653 Archived-At: Eli Zaretskii writes: >> > Which variables can safely and usefully be made thread-local? >> >> PT, ZV, BEGV > > Even that is not enough: you forgot the gap. Am I missing something, does the gap remain intact when the just move point? AFAIU, the gap only needs to move when we do edits. I was thinking about thread-local variables just to move around and read buffer. Asynchronous writing is probably a poor idea anyway - the very idea of a gap does not work well when we need to write in multiple far-away places in buffer. >> and the buffer-local variables that are represented by the >> global C variables. > > That's a lot! Do you mean that "a lot" is bad? >> > 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. It is, just not declared so. > 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. As I said, I hope that we can convert the important parts of the global state into thread-local state. >> 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. In short, pure functions in Haskell can utilize multiple CPUs automatically, without programmers explicitly writing code for multi-threading support. https://wiki.haskell.org/Parallelism In Haskell we provide two ways to achieve parallelism: - Pure parallelism, which can be used to speed up non-IO parts of the program. - Concurrency, which can be used for parallelising IO. Pure Parallelism (Control.Parallel): Speeding up a pure computation using multiple processors. Pure parallelism has these advantages: - Guaranteed deterministic (same result every time) - no race conditions or deadlocks Concurrency (Control.Concurrent): Multiple threads of control that execute "at the same time". - Threads are in the IO monad - IO operations from multiple threads are interleaved non-deterministically - communication between threads must be explicitly programmed - Threads may execute on multiple processors simultaneously - Dangers: race conditions and deadlocks *Rule of thumb: use Pure Parallelism if you can, Concurrency otherwise.* >> (declare (pure t)) > > How many of these do we have, and can useful programs be written using > only those? I think I did provide several examples. Po Lu also did. One additional example: Org mode export (the most CPU-heavy part of it). > ... More importantly, when you call some function from > simple.el, how do you know whether all of its subroutines and > primitives are 'pure'? We do not, but it may be possible to add assertions that will ensure purity in whatever sense we need. Having pure functions is not enough by itself - async support is still needed and not trivial. However, supporting asynchronous pure function is easier compared to more general async support. See the above quote from Haskell wiki. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at