X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=o68zcr6
	fLSjTaP8qt+oCh6YnD8L2KJ7L6FDa90awv080z6ADwt0u9s/5Z1BsrRdmjzwgnpO
	mFpMln+vXZQUs8GuVtCdmjWtD5EV875Fa1hAJJipsjrBGLIP7j0/rwLBc9IkYqb/
	9YEk68zPAvmt6/WDR+Ldi7HjV51snCVcHmyc=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=AM73rKhme3JmT
	dQu6uZ+Jv3POJI=; b=Wt8Pht6ZF3oxkOETYkoQLorSDwyemYwBxY+AL/3TTyyOi
	hSi2TkXcDzvwPaMud14w4xJJnHCbzDg4ICAyIV7WWfGo8OEFN5+f/Cmj8IO6L/2R
	cyk6xYgl8a/d7fu/ulHgrbFrwEV2tIJ7wavGIp8Hj38Mu6mLjzEgUjusexBrmE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:5284, communication, mechanism, highly
X-HELO:	mail-wm0-f49.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vzXmOa5o0tWOhWvV2sstoXY6LUO1HheyCFCE9A8NqSo=; b=mHAK4rqc0hhfuqjJ8PJrZkDtP4+5WLVFevkRivoMhV0RZMtliPsbqjHoLJElk5OSUk v7c7zQkGlazzFEO70ftrms0vuu+Vo0FXzXLknEuOztla5JzBcHrQA+D4vb053ST6zSBB +jh1KaYEf8yn33orYipGC+IGrkCWFoJmCnvQPBAA1S0zOLxxufHQZO4mKDSbr94a6rp/ 0nGCwTwWhtJ1VxNmyu8+Mzzkon/T00mNSdxMefhjE0WwGfTFBO3JdecRncoqdLN6TQHp 3nZI0HGN7gPBMj/cPeW5DAtXJgZDRvTCUoGIpnh+GEwv9lLefjvMbf2RBPTsHJJ+xzH6 5NBg==
X-Gm-Message-State:	AKaTC03nJeFIQ431sQiEP8MaezmBQp5iCJL2j/+Bx+LF4wVXydiDCueJR1EqD4j78vLwmr+qCV5jVSlYc4AcJQ==
X-Received:	by 10.28.9.80 with SMTP id 77mr28890696wmj.68.1480505749123; Wed, 30 Nov 2016 03:35:49 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<20161130104334.GB14074@calimero.vinschen.de>
References:	<CAOTD34ZFH5E3r3AuDOXctss46e1hoU2f9pwE1mt4L674J2Ak_A AT mail DOT gmail DOT com> <20161117140012 DOT GA23664 AT calimero DOT vinschen DOT de> <CAOTD34Y9TRq2Qq8Mn2awTf9SCgz0qnbBa-a117pkSEvz9gaHKQ AT mail DOT gmail DOT com> <20161130104334 DOT GB14074 AT calimero DOT vinschen DOT de>
From:	Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date:	Wed, 30 Nov 2016 12:35:48 +0100
Message-ID:	<CAOTD34b6L--aGJpzDuJzqEPdhOnPiVOYWW-UzK1kZ+RE_GsuHw@mail.gmail.com>
Subject:	Re: Retrieving per-process environment block?
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

On Wed, Nov 30, 2016 at 11:43 AM, Corinna Vinschen
<corinna-cygwin AT cygwin DOT com> wrote:
> Hi Erik,
>
> On Nov 29 14:26, Erik Bray wrote:
>> On Thu, Nov 17, 2016 at 3:00 PM, Corinna Vinschen
>> <corinna-cygwin AT cygwin DOT com> 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/<pid>/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/<pid>/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.
>
> You're right, it's not *that* straightforward.  I got carried away by
> the idea but didn't think this through when replying to you.
>
> So, how to implement this?
>
> We have two types of information in /proc/$PID, one is information
> readily available without having to contact the target process, the
> other information is local to the target process and we have to get the
> information with the target processes consent.  Argc, argv pointers
> are in the second group.
>
> So how do we contact the other process to ask for information?
>
> We have a mechanism inside Cygwin to request info from another process.
> It's part of the signal handling and consists basically of two
> functions.  The applicant calls _pinfo::commune_request(), this will
> send a request into the signal pipe of the target process, this in turn
> will call commune_process(), a callback function, within the target
> process.
>
> Have a look into an example:
>
> Start in fhandler_process.cc, function format_process_cmdline()
> which implements /proc/$PID/cmdline.
>
> It fetches the _pinfo pointer of the target process and calls
> _pinfo::cmdline.
>
> _pinfo::cmdline (in pinfo.cc) checks if the target process is a
> native Windows process a Cygwin process, or if its itself.
>
> In the native Windows case, it opens a handle to the target process,
> fetches its RTL_USER_PROCESS_PARAMETERS block (function
> open_commune_proc_parms).  and fetches the info from the target process
> by directly reading from its memory.  If it's itself it just constructs
> the info as desired and returns.  Boring.
>
> In the Cygwin case, it calls _pinfo::commune_request (PICOM_CMDLINE).
> PICOM_CMDLINE is defined in pinfo.h, together with other values for the
> commune requests.  It send the request over the signal pipe to the
> target process.
>
> The target process receives the request and calls commune_process().  It
> checks what info is requested, prepares the info and send it back over
> over the signal pipe.
>
> The (waiting) _pinfo::commune_request fetches the info from the pipe and
> returns to _pinfo::cmdline, which in turn returns to format_process_cmdline().
>
> So, ultimately, just copy the functionality of format_process_cmdline,
> _pinfo::cmdline, as well as the handling of PICOM_CMDLINE in
> _pinfo::commune_request and commune_process and you're done.

Hi Corinna,

Thank you for the detailed guidance on that--that all makes sense.  I
feel silly for missing that--I was actually poking around to see if
there was already something like that in the source but missed it.
For some reason I thought the cmdline was just stored directly in the
pinfo object itself.

But I knew, considering how signals are handled, that there had to be
some communication channel between processes; I just didn't know how
to use it for general purposes.  I just played around with it a bit
and I get the gist of how __SIGCOMMUNE works, etc.  Very clever.

I can see what to do now--thanks.

Erik

--
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

- Raw text -