From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture Date: Mon, 18 Sep 2023 23:38:24 +0200 Message-ID: <875y47yxf3.fsf@dataswamp.org> References: <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> <83ttrsg9nx.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="33794"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:17u50ro1eAWE+hB5BZgbnmJrQVU= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 19 04:22:26 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 1qiQNe-0008Xv-4N for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 04:22:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiQMd-0004j7-GJ; Mon, 18 Sep 2023 22:21:23 -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 1qiLx0-00042L-6F for emacs-devel@gnu.org; Mon, 18 Sep 2023 17:38:39 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qiLwx-0003cM-4V for emacs-devel@gnu.org; Mon, 18 Sep 2023 17:38:37 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qiLwu-0009Qn-LL for emacs-devel@gnu.org; Mon, 18 Sep 2023 23:38:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 18 Sep 2023 22:21:22 -0400 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:310733 Archived-At: Eli Zaretskii wrote: >> Again it would be interesting to hear of how other >> applications are doing it. > > There's a separate mutex for each global data structure. There should be a lot of experience doing that in C system programming not the least. Maybe we can bring something like that straight from some FOSS project? >> 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. But do we also have Lisp threads that execute on separate CPU cores in parallel, even tho they can't do anything sensible both simultaneously, for said reasons? We don't have that, right, because there is no reason to, as the threads are unable to lock individual resources anyway? So before we have a good reason to do that, we need to solve how a single thread locks a single, unlocked global data structure, access it's data, and then unlocks it? -- underground experts united https://dataswamp.org/~incal