From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Thu, 13 Jul 2023 13:54:37 +0000 Message-ID: <489f350ce60aea470c35@heytings.org> References: <871qhnr4ty.fsf@localhost> <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> <87pm518m0g.fsf@localhost> <17bc586130847440bbf6@heytings.org> <87bkgk6lps.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8633"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 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 Thu Jul 13 15:55:40 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 1qJwnD-0001yv-Go for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Jul 2023 15:55:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJwmL-0003Vh-UG; Thu, 13 Jul 2023 09:54:45 -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 1qJwmK-0003VW-DJ for emacs-devel@gnu.org; Thu, 13 Jul 2023 09:54:44 -0400 Original-Received: from heytings.org ([95.142.160.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qJwmI-0008HQ-Pa; Thu, 13 Jul 2023 09:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1689256478; bh=94zUKw6xEm3JbwCsWS9ZqA4DXjpoDXwKmnHJpt6MB+c=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=GE9Yf7fMcGzRAOfwxG8jD+zxxcs253Hoyl4QvuK/kDSG7ArogpGPfnb8Csh5PbirT jS2+SegN0yZoevORhfINpFLYUbiSNDWQyAdFhbOR49ErCIwKvLi9SrU/huyDVm4AeU DfrgZNoRRgDg5xlukcu+lIlQZfvM2z1AmvyZkgxNx2DahmJ3pzFGFt0QacJDqQoimM y62EGyIqNI+MVsq4zdNjeYhn8JMKWrS09sbDGCFmOFTJieXxhBngLJXIhONZeGON/o hcWqJVHaZj3phNLWWp62pdgCy5FlG5hrp7t6MUyq+FgOZ3Hp0G+Z/+QJbPvdBSjzUq JaoNqRD7DB3GQ== In-Reply-To: <87bkgk6lps.fsf@localhost> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:307819 Archived-At: > > while async threads will have to be written keeping in mind that global > variables may be changed during execution unless explicitly locked. > > And yes, we will need to implement locking on Elisp object level and > also on Elisp variable level. > It's not completely clear (to me) what you mean by "locking". But I assume you mean two operations lock/unlock with which a thread can request and waive exclusive access to an object, and sleeps until that exclusive access is granted. IOW, mutexes. If my guess is correct, that is not possible. You cannot use mutexes in a program whose data structures have not been organized in a way that makes the use of such synchronization primitives possible, without having deadlocks. Given that in Emacs objects are part of an enormous unstructured graph, with pointers leading from anywhere to anywhere, that's clearly not the case, and all you can use is a single global lock. But... > > But the very need to access global Elisp variables/objects from async > threads should not be considered a good practice (except near start/end > of thread execution). Most of processing should be done using threads' > local lexical scope. > ... if what you have in mind are async threads that should in fact not access objects of the main thread, why is it necessary to lock objects? You can prepare the arguments to the async thread in the main thread, start the async thread, and when its execution completes process the return values of the async thread in the main thread, which is what emacs-async already does. May I ask you if you have a concrete example of a task that you would like to perform with such threads, and that cannot already be done with emacs-async? In other words, what are the limitations of emacs-async you try to overcome?