From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70320 invoked by alias); 29 Nov 2016 14:12:11 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 68626 invoked by uid 89); 29 Nov 2016 14:12:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=wake, H*i:sk:CAOTD34, H*r:ip*192.168.0.6, highly X-HELO: mail-io0-f170.google.com Received: from mail-io0-f170.google.com (HELO mail-io0-f170.google.com) (209.85.223.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Nov 2016 14:12:00 +0000 Received: by mail-io0-f170.google.com with SMTP id a124so290838637ioe.2 for ; Tue, 29 Nov 2016 06:12:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5RsXaufsKkL19q6MagPtUZVwQqoMSJSCYgN1BVIDTnY=; b=V7VXMJzgOqA2d++c/K9unLuC9rl/Q73Z2ZN3v/GQM+PlfGNj9CTrVMA4S3NQwiORHs l6k4JTJgGIS+JICBTikgfXCqOpyg5gX6JyLQMRJDIPQkq+Z0KnKH35YT5yA9ht+KyhnE iRqsYZLpX00YziUnzz04u3cQZaNrHfszsq7j9m5sayWbC9fjUOtivd6kkuGD7gvnFp4l 6dlIpM+ClDM1OBCghDoSKDbJ+BA0ZoIZ+u5BWMyipbeb1OwsIVr017gLX3PUsYBazxx5 9LgLtEZbOglpYD5043QGGwGpNt2WyMr64T4Os+hB2/CPaZaz5Ezgk3eEcF5Ly36RCvvn perg== X-Gm-Message-State: AKaTC01dv7ZCG0+7DJKexMGxydVlcmkMdmGh75DQjZuD+iV0mSFL2frKNSckyistGyr5iw== X-Received: by 10.36.200.10 with SMTP id w10mr23358192itf.21.1480428718209; Tue, 29 Nov 2016 06:11:58 -0800 (PST) Received: from [192.168.0.6] (d27-96-48-76.nap.wideopenwest.com. [96.27.76.48]) by smtp.gmail.com with ESMTPSA id 130sm910345ity.5.2016.11.29.06.11.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 06:11:57 -0800 (PST) Subject: Re: Retrieving per-process environment block? To: cygwin@cygwin.com References: <20161117140012.GA23664@calimero.vinschen.de> From: cyg Simple Message-ID: <084579a5-19c0-8475-56bb-c0836ef7088f@gmail.com> Date: Tue, 29 Nov 2016 16:01:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00323.txt.bz2 On 11/29/2016 8:26 AM, Erik Bray wrote: > On Thu, Nov 17, 2016 at 3:00 PM, Corinna Vinschen > wrote: >> On Nov 17 14:30, Erik Bray wrote: >>> Hi all, >>> >>> For a quick bit of background, I'm working on porting the highly >>> useful psutil [1] Python library to Cygwin. This has proved an >>> interesting exercise, as much of the functionality of psutil works on >>> Cygwin through existing POSIX interfaces, and a handful of >>> Linux-specific interfaces as well. But there are some bits that >>> simply don't map at all. >>> >>> The one I'm struggling with right now is retrieving Cygwin environment >>> variables for a process (under inspection--i.e. not listing a >>> process's environment from within that process which is obviously >>> trivial). >>> >>> I've looked at every route I could conceive of but as far as I can >>> tell this is currently impossible. That's fine for now--I simply >>> disable that functionality in psutil. But it is unfortunate, though, >>> since the information is there. >>> >>> There are a couple avenues I could see to this. The most "obvious" >>> (to me) being to implement /proc//environ. >>> >>> I would be willing to provide a patch for this if it would be >>> accepted. Is there some particular non-obvious hurdle to this that it >>> hasn't been implemented? Obviously there are security >>> implications--the /proc//environ should only be readable to the >>> process's owner, but that is already within Cygwin's capabilities, and >>> works for other /proc files. >> >> Patch welcome. Implementing this should be fairly straightforward. >> The only hurdle is winsup/CONTRIBUTORS ;) > > Thanks--I went to go work on this finally but it turns out not to be > straightforward after all, as the process's environment is not shared > in any way between processes. > > I could do this, if each process kept a copy of its environment block > in shared memory, which would in turn have to be updated every time > the process's environment is updated. But I don't know what the > impact of that would be performance-wise. > > Any advice? > Sounds like a job for a thread that wakes every X time units to check the contents of the environment. Or is there a notification API that could be used to wake the thread? I know there is a disk change notification API for this; maybe one for environment changes as well. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple