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 21:26:12 +0200 Message-ID: <868r31rbxn.fsf@gnu.org> References: <86cysdrja3.fsf@gnu.org> <86a5nhrdv0.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15948"; 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 20:26:58 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 1rg8X3-0003vX-Uj for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Mar 2024 20:26:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rg8WT-00056j-DW; Fri, 01 Mar 2024 14:26:21 -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 1rg8WQ-00052E-VY for emacs-devel@gnu.org; Fri, 01 Mar 2024 14:26:19 -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 1rg8WP-00019g-UY; Fri, 01 Mar 2024 14:26:18 -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=HuObemJHkKrUKk3LJr7SBqpRYiVPfW234zBKpDoehK0=; b=IBCj6kKy9m+B OMISgwf3rczRmVhbII5Wnxit58VH2RZJ6phV1td8K6c49sav+OROXpBWe1RfSUjuJhihdAEeSzGm5 Tz7n+AtYwetnO8bYaXesOWSQTiem/9i09v+aL/QNVJ3050PTP/dxN1mGUE8GzxcVXDZMkUnbo6g9i bBjqCl/+lAjcxGtr7BRFCrfSVshBEHnzMtyrW/c6u6IGcpmrz0CgPLhk0827u3/3CGbJ9MJhyjcBd epL3eE1TsPZnQWin2iErtsI3epWeLw6/ac9kgy89UfVDYXQh2cXL5gc0ZEXwXPlqlmBUHx2JQfDki 4snWJZ5UaFJoVAs9+hfdQg==; In-Reply-To: (message from Spencer Baugh on Fri, 01 Mar 2024 14:02:24 -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:316676 Archived-At: > From: Spencer Baugh > Cc: emacs-devel@gnu.org > Date: Fri, 01 Mar 2024 14:02:24 -0500 > > Eli Zaretskii writes: > >> > I think this is already possible, see above. I guess I'm missing > >> > something. > >> > >> I don't think it is. How would a module release global_lock, call a C > >> library function on the current thread, and then re-acquire the global > >> lock? Can you say how you would do that with the APIs we have today? > > > > If a thread releases a global lock, it cannot run the Lisp machine > > until it re-acquire the global lock. > > Yes. But calling a C library function (by some other library not > related to Emacs but used by the module) does not involve calling into > the Lisp machine or any Emacs machinery. 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. > So, because it does not involve calling into Emacs, we could allow > the thread to make that call without the Emacs global lock which > protects Emacs. Once again: you can do that if you start a native thread before releasing the global lock. Why is that not a solution to what you have in mind?