From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.devel Subject: Re: Environment variables in dynamic modules Date: Fri, 12 Jan 2024 09:29:11 +0900 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006c3d53060eb4c13f" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28706"; mail-complaints-to="usenet@ciao.gmane.io" To: sbaugh@janestreet.com, Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 12 01:29:51 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 1rO5Qj-0007CB-FX for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Jan 2024 01:29:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rO5QN-0006kj-Ni; Thu, 11 Jan 2024 19:29:27 -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 1rO5QL-0006f7-Kk for emacs-devel@gnu.org; Thu, 11 Jan 2024 19:29:25 -0500 Original-Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rO5QJ-0001nP-Tm for emacs-devel@gnu.org; Thu, 11 Jan 2024 19:29:25 -0500 Original-Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-dbeda700015so5067519276.2 for ; Thu, 11 Jan 2024 16:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1705019362; x=1705624162; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Tm2vXApivrGgxFTkpTQQCcJav7kQvCRatgNBwJSZMKA=; b=MmAkx/jKeSQJPyiECWu7piYkZv/frHsODeNT7u1q/9NNQOz3PYRx9ZFgF3ew4jf+gb VSM3wK8OTCkuHivRs+jiDdz4orvxvCvJSvWWtzoi2xmAwkoDawkI5cs0yAzk0PFFKshW eV+OY6ptXhzRu2IbXTcwlKNCbm8zhaetltJC9NER9s9s+pRMPqin2epq07UqqsnmVql2 mRDbJ2Hu7gbaGLLMy0l+Szo52otM5CgBbYsfFwVUDCZ/katOV/rsX6liF5VM3uoaBarA kiyZABUnE1AbrRbA0/43SO1khixOgBWw+qDyHKzTuWB+dMXD9uuvaGiD7Mex8IEPiM/l tf0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705019362; x=1705624162; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Tm2vXApivrGgxFTkpTQQCcJav7kQvCRatgNBwJSZMKA=; b=l4jMnWag7tx1CFzSjctg6C3cxcBt9tiunszNuNzSJktFTczuDyzmx0iH2k3leEvcNG Nn7nhvDtyOFiHNiSMU9kmCW2FOH6CAjkiVkSPNF9WSJsUtk2g+Y4iyDOBoJ5Fo+HYXAC M3/CBMKI1PGKH+XVZ7DBFycAIp1jnvgSm2sIH81pVenHVLtVVLQ65gs6BJ+qxSgAZ3T4 /eu02uF4ee9K1/A3+nd2BTUmVyBmmPxi+pKboV+uVL1XO3uPgNw3QkRMwWmErKpLqdC2 i5k6H6YxJHJ2pzp9Q4Dm58c+4/0N6YtGxghFVOhXVGSRJAv83ZDAIqZxe+xyGbPFXX+e 7w5A== X-Gm-Message-State: AOJu0YwHyGks36c9C5w2VvuCpOy9Y9cgADggTI80sQYAh+OP2Wkkd67f uuxhaEHzIgYjuJTLQ+9H6OH6MTB1O+KIQI0LnnicuH+Nj6PH109HU5J1z4x3wce1Dw== X-Google-Smtp-Source: AGHT+IGOZP0vCyKf1BayXvEh9ijxc11Iq9s/VEB8TgdbpruGoVG6ZtxE0QFXC6RK2+oH65MS0IZl/RAbx2dX949Ru8I= X-Received: by 2002:a25:ac27:0:b0:dbc:cb56:8a30 with SMTP id w39-20020a25ac27000000b00dbccb568a30mr50460ybi.118.1705019362256; Thu, 11 Jan 2024 16:29:22 -0800 (PST) Received-SPF: pass client-ip=2607:f8b0:4864:20::b31; envelope-from=exec@positron.solutions; helo=mail-yb1-xb31.google.com 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:314882 Archived-At: --0000000000006c3d53060eb4c13f Content-Type: text/plain; charset="UTF-8" >> 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) I'm going to preface a solution to excessive redundant passing by pointing out that the provenance of a piece of data is a requisite but something we don't have. Encoding input provenance in vector clocks is a solution to avoiding unnecessary passing and maintaining caller and callee input synchronization even when the callee is performing asynchronous work. While we can use watch-variable for updates from Elisp, such as those done by a package like envrc that creates buffer local environments, updates from C don't have this convenience. Protecting inputs from arbitrary mutations is a requirement to implement this technique conveniently. More likely, there need to be interfaces that permit a logical clock and the value it versions to remain consistent. Since the data needs to be immutable or else requires locking, coordination with the GC is required. --0000000000006c3d53060eb4c13f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> C. Set all variables in the C environment to matc= h process-environment
>> =C2=A0 =C2=A0every time we call into the = dynamic module
>> =C2=A0 =C2=A0(but this is slow and hurts perform= ance)

I'm going to preface a solution to excessive redundant passing by pointing=20 out that the provenance of a piece of data is a requisite but something=20 we don't have.

Encoding input provenance in vector clocks= is a solution to avoiding unnecessary passing and maintaining caller and callee input=20 synchronization even when the callee is performing asynchronous work.
=

While we can use watch-variable for updates from Elisp,= such as those done by a package like envrc that creates buffer local envir= onments, updates from C don't have this convenience.=C2=A0

Prote= cting inputs from arbitrary=20 mutations is a requirement to implement this technique conveniently.=C2=A0 = More likely, there need to be interfaces that permit a logical clock and th= e value it versions to remain consistent.=C2=A0 Since the data needs to be = immutable or else requires locking, coordination with the GC is required.
--0000000000006c3d53060eb4c13f--