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: Environment variables in dynamic modules Date: Thu, 11 Jan 2024 19:02:22 +0200 Message-ID: <835xzzls69.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22145"; 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 Thu Jan 11 18:04:19 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 1rNyTb-0005VJ-Dr for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Jan 2024 18:04:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNySI-00063i-Kl; Thu, 11 Jan 2024 12:02:58 -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 1rNyS8-0005a8-KN for emacs-devel@gnu.org; Thu, 11 Jan 2024 12:02:52 -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 1rNyS3-0004RS-QA; Thu, 11 Jan 2024 12:02:45 -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=65p32wuycJBlS3kqZoNnWri9d3IXPeLWG1dm2i584Vo=; b=OSQBCjkavIY6 4sKEVqPx0prR+C+SAMNIGkgyyzHxuNUt1PYB0Zp+bpcDTE9oweclaHmOIEV+tomQ10l/nWPcBGJYW Kq7OydtT9cRDaM1bk09wg5VWt6y4KQjiQo3S/5aZnY487rAcUmWh6NsZoVym8JCax07S0bIErGS28 T1sBuC8tCEzeFcvjLq7qAz6odeK8eyNruc/SClQK1RRNgjW2kiH4vbo1vHyLNsbLyxFVfsFVx2nWO DNwxLjl7IOAxZC0IrpeW2u/qifCsn9Awpq5IxMYG46PTF6XvWWdMc1VpJMuXIuyCnMd3T9z/9kK3Y q8Sri22ra9j3udJj+mTieQ==; In-Reply-To: (message from Spencer Baugh on Thu, 11 Jan 2024 11:03:25 -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:314863 Archived-At: > From: Spencer Baugh > Date: Thu, 11 Jan 2024 11:03:25 -0500 > > > In Emacs, process-environment (read by Lisp getenv) is distinct from C > environment variables (read by C getenv). > > This means that a dynamic module which links against a library which > reads environment variables will not be affected by changes to > process-environment. > > For example, if a user calls (setenv "VAR" "value") or binds > process-environment to (cons (cons "VAR" "value" process-environment)), > a getenv("VAR") in the dynamic module library won't return "value". > Likewise, if a dynamic module spawns subprocesses, they will inherit the > environment that the Emacs process started with, not the current > environment in process-environment. > > This is usually unexpected, and causes difficult-to-track-down bugs, > especially for dynamic modules that spawn subprocesses or for large > dynamic modules with lots of functionality. > > There are a number of possible ways to solve it: > > A. Carefully track down every place that a library reads environment > variables or spawns subprocesses, and pass in the Emacs environment > instead. > (but this is intractable in modules which call other libraries) > > B. Advise Elisp setenv to also change the C environment > (but this doesn't work with let-bindings of process-environment) > > C. Set all variables in the C environment to match process-environment > every time we call into the dynamic module > (but this is slow and hurts performance) > > D. Use linker tricks to replace C getenv with a version which calls back > into Emacs. > (but this doesn't work on other threads, since we can only call into > Emacs from the main thread) > > None of these are particularly satisfying. I have implemented D, but > since my module uses multiple threads, it doesn't really solve the > problem for me. > > Any suggestions? The only correct solution is C, and you should only do that in the module when the module calls something that really needs the environment. D is not portable, since a library that was linked to use getenv from libc will not necessarily call getenv that you provided, at least not in all systems. I don't know why you say C is slow; did you time it? You could, of course, set only some of the environment variables, those that matter, instead of setting all of them. Libraries that want to allow their callers to manipulate the environment should do that themselves where needed. Only the library and its callers know when it's TRT to modify the environment and when it is not, so no 3rd-part code (such as something in Emacs) can do that for them. For example, how Emacs know that some library called by some other library that your module calls needs to see the modified environment that Emacs uses? It makes little sense to me to do this in Emacs, since most modules don't care about the changes to process-environment done by Emacs.