From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Po Lu <luangruo@yahoo.com>
Newsgroups: gmane.emacs.devel
Subject: Re: Concurrency via isolated process/thread
Date: Sun, 09 Jul 2023 15:14:36 +0800
Message-ID: <87o7kleeub.fsf@yahoo.com>
References: <871qhnr4ty.fsf@localhost> <831qhmjwk0.fsf@gnu.org>
 <875y6y8nlr.fsf@localhost> <87h6qhnalc.fsf@yahoo.com>
 <87ilax71wo.fsf@localhost> <831qhli14t.fsf@gnu.org>
 <87wmzdxewc.fsf@localhost> <83r0plgjeo.fsf@gnu.org>
 <87o7kpxapo.fsf@localhost> <83mt09gcaf.fsf@gnu.org>
 <87wmzbc3af.fsf@localhost> <87edljhmjq.fsf@yahoo.com>
 <87fs5zbuwn.fsf@localhost> <871qhjgrku.fsf@yahoo.com>
 <831qhieumz.fsf@gnu.org> <87lefqg7yl.fsf@yahoo.com>
 <83h6qed8kw.fsf@gnu.org> <87h6qefwj0.fsf@yahoo.com>
 <83bkgmcx0q.fsf@gnu.org> <87a5w5gbs4.fsf@yahoo.com>
 <83bkglbmai.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="20292"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cc: yantar92@posteo.net,  emacs-devel@gnu.org
To: Eli Zaretskii <eliz@gnu.org>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 09 09:15:44 2023
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1qIOe0-00055V-HW
	for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 09:15:44 +0200
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1qIOdB-0002L8-J2; Sun, 09 Jul 2023 03:14:53 -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 <luangruo@yahoo.com>)
 id 1qIOd9-0002Ke-EP
 for emacs-devel@gnu.org; Sun, 09 Jul 2023 03:14:51 -0400
Original-Received: from sonic314-22.consmr.mail.ne1.yahoo.com ([66.163.189.148])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <luangruo@yahoo.com>)
 id 1qIOd7-0005PK-GC
 for emacs-devel@gnu.org; Sun, 09 Jul 2023 03:14:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1688886886; bh=UJMxGIKv93pmBRdwAiQr0UG21j/PIcwSR7Lna62sXIY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To;
 b=oqayTKF3pnMKTGItO9g0CH0oAzqtYDQShM643s0a/R2Il321nEOSRgvjCJo0BYnW+sL8UT970oMQTlmIgDUa47/IcFO77gP5UI2xhCeiq3rp58AgdKvgiHykilcGXFFilJaWhHDWUd+UoKq+msV/NRnXQ+XyNvY3d8ayiwYNqwgojmwcI5oisrSIXDJV04jkNPF3xzNo4YeJbrVYFbSqQw+FFCx2B/R94yY8uLTfuPDz5LCN4m3qbpUih90KmJACXRaRNqyXcYrXK5yXYKGlY6ETU8b2fdNuf0ag5pLnLjK6GwQ+OtbpRjD0qy+ckfvly3iY/n+dMTWV+zgx/SmUYQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1688886886; bh=fsscC3Unxo0/BIbqAEPuNFqw4nAg5R6hLB0tIQ/ZaZj=;
 h=X-Sonic-MF:From:To:Subject:Date:From:Subject;
 b=Zy3yZ3ZxXIFfNSTb4VWHP+C2KckpCm9WirkdmDsgLwRJd4X4I8Yz+s0icLqVFOr6kmSfaSkleD9cD02asXSWaE1qJ4thwKuVdPL9S3k6G7VxVLAkw5iWL9EcnmXMkJFjECs6fZ34zMEJeITRJ3ywF2wIdiAERhGi9FHw6waPk698ZFuKnEV8yXEdzNUMkjfiZPezLAoirBy4x6djesOWRhjfGG0o02ZrAyBbrv7fnm+S3y3idFldTlDoKHNdEGX1CMbZcsOpc2aKcldWycE1cTyi4tYx0i3iOXytoihoqro5/Jg65+UBJTPZbWkiQfXRs/y/IpS5dfpHDUOFz/NuFw==
X-YMail-OSG: uu3QoFUVM1n28qJRiks_dv0fBSspFRf7rwERzD8Z5srgCh.Duyx6BG13tMNHE6u
 i.wbN9ZOeWR7rwSCfX.rqwBd7iJvfBAHXZI2zoKLvTjdTMNeHFTXYESI4QRcbzhhUPxOqfm9US31
 aLfTpPoYv2una85WaEqwEEngai_mY3.fwoQgmJVTD5L3z.SPwFNwf49I.r4h5o_66rdmT0q6AM8H
 bFNTdpzf_ViXtTZGdrqDfH6zPw2UWJKd2m5aBe2NUaId0yuv50t9PY..lSSGfV1lNButrNtQhfWU
 TavcP2bIuu5IuToKgux9Hq3kkdW7ZnSCJSn.GA5L9PhqWyh.EnJQ0d6bJPw4XDnEprrP.EJLmnzo
 OPcdYvZZaSF5M3sh.nsJx9l7ZzJ10dUc4NDhNrcn1mYr1zMVI89RkptHwkwxLxr9TLbfXGfhijQy
 8JY_IAg6xdtk1lObQc8oj7kJoSDB2BtQKNTHNqqK2KKDuAcwn.Qpue_oXSwfSZvCWBdXo03WFuy3
 5MpyIe9UhRcVzK5Y7yncpYC4Q8dHLqOe42kzMRU6ch1OzU..QlTR9Uo.nXoxvaPGcAXHwyFS92H7
 ThK7dxp0OdKqD3hR6oH5tNM6lEE1SrW8GaMDElc.J.ckMoKp8RgVL7mv7WDnxLBQnnynUizVORBw
 9q5cyvpMd3s8X_Bv_adH.7BUrIS2QARFxPygT8hfiStfyTn6EV7tW9MuK1N2HT2CY8B0cKwAls_L
 YmvxPEmg17xFAAKvrakb1QOYh1fwqDBW8qbtLqFsEGilXB349iSOKV4vKdlLJ0cukvHg2dQMnT05
 w2IBxkDlThZX8XDYs7AJDEysE9JFWn6pMtseYDHlRq 
X-Sonic-MF: <luangruo@yahoo.com>
X-Sonic-ID: b76d30f0-a34c-4908-8c5d-1d288e334eaa
Original-Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sun, 9 Jul 2023 07:14:46 +0000
Original-Received: by hermes--production-sg3-67fd64777-lqw65 (Yahoo Inc. Hermes SMTP
 Server) with ESMTPA ID 52d6c4169ed63b280b44fd3ac9aff17c; 
 Sun, 09 Jul 2023 07:14:41 +0000 (UTC)
In-Reply-To: <83bkglbmai.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Jul
 2023 10:01:57 +0300")
X-Mailer: WebService/1.1.21638
 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo
Received-SPF: pass client-ip=66.163.189.148; envelope-from=luangruo@yahoo.com;
 helo=sonic314-22.consmr.mail.ne1.yahoo.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=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:307643
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/307643>

Eli Zaretskii <eliz@gnu.org> writes:

> That is of course not always possible, or even desirable.  For
> example, some prompts are caused by specific aspects of the
> processing, which may or may not happen, depending on the data.
> Prompting for options unrelated to the actual processing would mean
> annoying users unnecessarily.  Etc. etc.

In that case, the thread will have to suspend itself until the main
thread can read a response from the user.

> So basically, what you have in mind is a way of accruing a body of
> special-purpose Lisp programs written specifically for running from
> non-main threads.  Which means reusing existing code or packages not
> written to these specifications will be impossible, and we will in
> effect have two completely separate flavors of Emacs Lisp programs.
> It would mean, in particular, that many functions in simple.el,
> subr.el, and other similar infrastructure packages will need to have
> specialized variants suitable for running in non-main threads.

Yes.

> And all this will be possible if -- and it's a large "if" -- the
> necessary support on the C level will be written and prove reliable.
>
> If this is the plan, it might be possible, at least in principle, but
> is it really what is on people's mind when they dream about "more
> concurrent Emacs"?  I doubt that.

I don't know what other people think, but it's what I would find
desirable, as my gripe with tools like Semantic is that they cannot run
expensive text crunching tasks in the background.  Having shared-memory
multiprocessing would allow these tasks to be implemented efficiently.

> Memory is cheap these days, and "slow IO" is still a gain when it
> allows us to use more than a single CPU execution unit at the same
> time.  So yes, efficiency is desirable, but ease of use is also
> important.  What's more, I don't think anyone really wants to have to
> write Lisp programs in a completely different way when we want them to
> run from threads.

When programmers write such code for other interactive programs, they
are comfortable with the limitations of running code outside of the UI
thread.  Why should writing new, thread-safe Lisp for Emacs be any more
difficult?

> Those mechanisms only work when Emacs is idle, which is bad for
> features like progress reporting.  Doing this right requires to
> redesign how redisplay kicks in, and probably have several different
> kinds of redisplay, not one.

Maybe.  I haven't worked out the details of that yet, but in most other
GUI programs and toolkits, messages from other threads can only be
processed by the UI thread while it is idle.

> I think none of them are side-effect free, if you look closely.  They
> access buffer text, they move point, they temporarily change the
> selected window and the current buffer, the access and many times
> modify the obarray, etc. etc.

`intern' should be interlocked so that only one thread is accessing the
obarray at any given time.  Point and buffer text shouldn't prove a
problem, provided that the buffer being used is not accessed from any
other thread.

But yes, many of these functions will have to be audited and possibly
rewritten for multi-threaded correctness.