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: Emacs design and architecture Date: Sun, 17 Sep 2023 17:24:18 +0300 Message-ID: <83ttrsg9nx.fsf@gnu.org> References: <83r0n4rj78.fsf@gnu.org> <83cyynpmvd.fsf@gnu.org> <838r99mh40.fsf@gnu.org> <83h6nwlmt4.fsf@gnu.org> <456d12ac-ecf4-3de4-56bb-a2440580777f@gutov.dev> <83a5tokmsv.fsf@gnu.org> <83sf7fki5g.fsf@gnu.org> <43d642a8-d1b4-05ed-41e0-6e52d22df2d4@gutov.dev> <83edizjn0v.fsf@gnu.org> <0518f65b-1dd1-6923-8497-da4d3aeac631@gutov.dev> <87sf7fc7kd.fsf@dataswamp.org> <834jjuk68t.fsf@gnu.org> <87cyyhc7uu.fsf@dataswamp.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25234"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Emanuel Berg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 17 16:25:13 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 1qhsi0-0006KE-UQ for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Sep 2023 16:25:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhshB-0002ig-B3; Sun, 17 Sep 2023 10:24:21 -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 1qhshA-0002i8-F5 for emacs-devel@gnu.org; Sun, 17 Sep 2023 10:24:20 -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 1qhsh9-0000hF-Fp; Sun, 17 Sep 2023 10:24:19 -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=YbrkDh3KvBFDV75NKMEne2Qj2s7zaAB4ZCcN0L9kyYg=; b=dq62uvej/KRm YzBziANMlYFlA5Ko5WJjO6O2EnsWHQateh4FetEhnmlHUqbvvjOBymn2q5nh/x34C+1w7NJfiVRgT qmASel2WrR6KoEUNuSW5OZkLwyviKBHMaqlcwP8zpDJuZeJeYJp2sXqLAS2UCmbNxJKdFD6XB0Ubc 5mcGzFjVSF1pPTZz6wEe64jYVdK2oQA6KqER15aZ2jv4d7Zxf/xzWvcsl9Mg8ZoWxlKkIwCRH53tx CKd6UlEg0wnnR9iYX2AA6SkYpVf8aNyXaa6WiBArtNnUMolQpWt/sUGNo9vSorNF16+O/wSNS6pSw gZtzkpTO86zOT57bOQHX8Q==; In-Reply-To: <87cyyhc7uu.fsf@dataswamp.org> (message from Emanuel Berg on Sun, 17 Sep 2023 14:16:57 +0200) 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:310664 Archived-At: > From: Emanuel Berg > Date: Sun, 17 Sep 2023 14:16:57 +0200 > > Eli Zaretskii wrote: > > > If you know how to do one of them, you also know how to do > > the other, because Emacs is a Lisp machine. > > How do other applications, that are multi-threaded, solve the > same obstacle, i.e. that of concurrent access to a big, shared > global state? Mult-threading and global state are two opposites: an application that wants to be multi-threaded should have as small a global state as possible, and where it cannot be avoided, use locking to access global state from different threads. > Because if the whole thing has to be locked for each thread to > access, it can be disputed if that is indeed any parallelism > at all. It will be multi-threaded and multi-core alright, but > not parallel execution unless one counts waiting for a shared > resource to become available as a sensible passivity. That's what we have with Lisp threads now: while one thread runs, all the others are stopped by a global lock. > So one would have to have a more fine-grained access to the > resource - by splitting it up in pieces. That way one thread > could access r_i while another accesses r_j and so on. This was discussed here earlier, and ion is that it's easier said than done. > Again it would be interesting to hear of how other > applications are doing it. There's a separate mutex for each global data structure.