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: Tue, 25 Jul 2023 17:27:04 +0300 Message-ID: <83h6psoymf.fsf@gnu.org> References: <871qhnr4ty.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> <87pm518m0g.fsf@localhost> <83o7kl9tyj.fsf@gnu.org> <874jmd89us.fsf@localhost> <878rb53dkj.fsf@localhost> <83edkxsclz.fsf@gnu.org> <87tttt1mzh.fsf@localhost> <83351ds9de.fsf@gnu.org> <87ila91j6n.fsf@localhost> <83y1j5qoyo.fsf@gnu.org> <87wmypi7s0.fsf@localhost> <83cz0gqlee.fsf@gnu.org> <871qgwnr7j.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31489"; 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 Tue Jul 25 16:27:39 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 1qOJ0l-0007wP-9X for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jul 2023 16:27:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qOIzX-0001YL-Rq; Tue, 25 Jul 2023 10:26: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 1qOIzW-0001Y1-Md for emacs-devel@gnu.org; Tue, 25 Jul 2023 10:26:22 -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 1qOIzW-00032q-6V; Tue, 25 Jul 2023 10:26:22 -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=PqHRdUXnnpMhqjPuSI94jYosmrFyHBRUfKi7Nk+4OzI=; b=HltgxS/BLdJB vwPb9QsbQ4Zk6LrHH0/vkeMkM7G0JbVJh/4Go0kPFWJmMp5kIDB45lEGOQtTmaJczXNdYsN8nCLWn Fky9fRcZMZ9H72boHZh3EenH/CYT/VNYhNnkKXOlGXDw39O8gNmzf3F51e2BhCCY0s0xp+4ycY3El VzamAqPPRUDMRt9cc2xiVzFd7iio7u1NZk/0ekSVoG8PmpOw5tcKsHgDFF4GNtXTp0StdugnZrAwc lETafV/RhR5bk6BF8dDIy3hF8oDyfoO9+MN1TCMfq5rPcizAv21hMSAz3yrT3yaVsLseKockd9BO7 TZuyaGCoDVGu3QYNGKwbQA==; 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 1qOIzU-0003LW-Oa; Tue, 25 Jul 2023 10:26:21 -0400 In-Reply-To: <871qgwnr7j.fsf@localhost> (message from Ihor Radchenko on Tue, 25 Jul 2023 11:52:32 +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:308101 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Tue, 25 Jul 2023 11:52:32 +0000 > > Eli Zaretskii writes: > > >> Of course, such write locks should happen for short periods of time to > >> be efficient. > > > > How can this be done in practice? Suppose a Lisp program needs to > > access some object, so it locks it. When will it be able to release > > the lock, except after it is basically done? because accessing an > > object is not contiguous: you access it, then do something else, then > > access it again, etc. -- and assume that the object will not change > > between successive accesses. If you release the lock after each > > individual access, that assumption will be false, and all bets are off > > again. > > This is just a basic problem with any kind of async code. Async code avoids accessing the same object as much as possible, and if that's not possible, uses synchronization features. You also suggest using synchronization feature, and there's nothing wrong with that -- except that if those are used to lock buffers and global objects, we no longer have true concurrency, because in many cases only one thread will be able to do something useful. That is all I'm saying. If you agree, then this whole development sounds questionable, because it will require massive changes for very little practical gain, and with many disadvantages, like the necessity to call synchronization primitives from Lisp (which makes it impractical to run the same Lisp program with and without concurrency). Bottom line: I think your view of what will need to change vs what will be the costs is very optimistic. We have only scratched the surface of the subject, and already there are quite serious issues and obstacles to be negotiated. Feel free to work on devising solutions, but my gut feeling is that this is not worth it, and that Emacs cannot be adapted to true concurrency without a very thorough redesign of the core data structures and rethinking of the main architectural assumptions and models. E.g., do we even believe that MVC is a proper architecture for a multithreaded program? And one other remark: please always keep in mind that Emacs is unusual in the depth and intensity of the control it lets Lisp programs have on both input and display. Any significant architectural change will have to live up to the expectations of Lisp programmers who are used to the level of control they have in Emacs. Providing the same level of control when input and display run in separate threads from the Lisp machine, let alone allowing several Lisp threads run in parallel and complete for such control, might prove much more difficult. But if not provided, this will no longer be Emacs, and will not be as popular with the present community. That's an additional uphill battle any new design will have to fight.