From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Environment variables in dynamic modules Date: Thu, 11 Jan 2024 11:03:25 -0500 Message-ID: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19016"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:T1ziEKn6i7yXyyzlezE2fisFmrY= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 11 17:12:06 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 1rNxf4-0004rc-De for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Jan 2024 17:12:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNxee-0003yK-5l; Thu, 11 Jan 2024 11:11:40 -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 1rNxWq-0005zc-MD for emacs-devel@gnu.org; Thu, 11 Jan 2024 11:03:36 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNxWo-00006g-U9 for emacs-devel@gnu.org; Thu, 11 Jan 2024 11:03:36 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rNxWm-0002Js-2t for emacs-devel@gnu.org; Thu, 11 Jan 2024 17:03:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 11 Jan 2024 11:11:38 -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:314860 Archived-At: 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? Personally, I think some variation on B or C would be nicest, if it could be done in a performant way which also works with let-bindings of process-environment. But I don't know how to do that.