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: Releasing the thread global_lock from the module API Date: Fri, 01 Mar 2024 22:42:44 +0200 Message-ID: <865xy5r8e3.fsf@gnu.org> References: <86cysdrja3.fsf@gnu.org> <86a5nhrdv0.fsf@gnu.org> <868r31rbxn.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7916"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 01 21:43:36 2024 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 1rg9jD-0001rl-B0 for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Mar 2024 21:43:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rg9iV-0004dh-RB; Fri, 01 Mar 2024 15:42:51 -0500 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 1rg9iT-0004Vm-BS for emacs-devel@gnu.org; Fri, 01 Mar 2024 15:42:49 -0500 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 1rg9iS-00077o-8Z; Fri, 01 Mar 2024 15:42:48 -0500 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=yin7sU/dLHyXqvZy+bsnrS+pOJngYMQGvqVW6mz4PGc=; b=hyCQk4lC/wpG eNuz3YxaMxihUL85u4vrjk9dthFEv2exPWzpxRIVsXEJKuG6ZEnuRYXSq6qAOuvawR1bpoJ7yiCTj ekmuFVGm80VRl3WzjiKR3GVH0iUEjwZoCg/R0UldsdrBRnplM/hgUKAep1U3mvdEPpAcS2sE91Kkj 0SPdFKt96tSn7hr3Yg/WKSo9QG1AzqBdFXKIEv8Qwae2tesFNRQo9QTbAfKyUfVaj9LnpQLlfKUid N6dIDTX/o+8+4zyLS6y1mUxczBKGi7btbNcRUPIwefGEZcNZLopCSxm6MeNFc9WKDbwwTzzNpoxC8 Dl7gdaX2W9Jj2+F/NVtiaw==; In-Reply-To: (message from Spencer Baugh on Fri, 01 Mar 2024 14:51:01 -0500) 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:316679 Archived-At: > From: Spencer Baugh > Date: Fri, 01 Mar 2024 14:51:01 -0500 > > Eli Zaretskii writes: > > > There's very little you can do usefully this way without touching some > > aspect of the Lisp machine. Assuming that what you do has some > > relevance to the Emacs session, of course. > > Actually, there is lots of useful stuff that can be done this way. > > For example, if a C library internally opens a network socket and sends > a request to a network service, that does not touch the Lisp machine and > so can be done this way. > > Is that not useful? Or do these touch the Lisp machine in some way I > don't know about? Where would you take the data for opening the socket? doesn't that come from some Lisp program or from a Lisp variable? And how would you know what kind of request to send? doesn't that come from Lisp as well? And what would you do with the stuff you get in response? don't you want to put this in some Lisp variable or provide as input for some Lisp program? Etc. etc. > Since it's useful for me, I'd like to write a patch which allow modules > to do this; would it be considered? Once again: what cannot you do from a native thread started by the module? IOW, why would you need access to the global lock machinery in the first place, if all you want to do is something that is unrelated to Emacs and its global state? The code which manipulates the global lock is extremely fragile, so exposing this to external agents without a very good reason and without being able to fore some discipline is a bad idea. And I don't yet see such a good reason, let alone how to do that in a way that will preserve the discipline of taking and releasing the lock. So please do try to explain better why native threads that are unrelated to the lock are not the solution for what you have in mind.