public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Retrieving per-process environment block?
Date: Wed, 30 Nov 2016 15:04:00 -0000	[thread overview]
Message-ID: <20161130122939.GC22541@calimero.vinschen.de> (raw)
In-Reply-To: <CAOTD34b6L--aGJpzDuJzqEPdhOnPiVOYWW-UzK1kZ+RE_GsuHw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3767 bytes --]

On Nov 30 12:35, Erik Bray wrote:
> On Wed, Nov 30, 2016 at 11:43 AM, Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> > 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.

There's a catch.  The shared mem regions maintained by Cygwin are
supposed to fit in one allocation page, that is, 64K, at a reproducible
slot in the processes VM (think fork).  Variable size information,
especially information which can have an almost arbitrary size, is quite
tricky to be held in shared mem.

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

Curtesy cgf.  The commune mechanism obviously depends on the reliability
of the signal handling.  It also has a problem in that, since it's a part
of signal handling itself, it can't be interrupted by signals.  In earlier
stages it was pretty bad, but at one point we just changed the pipe calls
to timeout after 1 second each, so either it works or it times out after
a max of 2 secs and the information is just not available on the client
side.  There's worse than that.

> I can see what to do now--thanks.

Cool.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2016-11-30 12:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17 18:05 Erik Bray
2016-11-17 18:11 ` Corinna Vinschen
2016-11-29 15:28   ` Erik Bray
2016-11-29 16:01     ` cyg Simple
2016-11-30 11:03       ` Corinna Vinschen
2016-11-29 16:35     ` Eliot Moss
2016-11-29 17:42       ` Erik Bray
2016-11-29 18:02         ` Andrey Repin
2016-11-30  4:28           ` Herbert Stocker
2016-11-30 10:43             ` Eliot Moss
2016-11-30 10:47               ` Peter Rosin
2016-11-30 10:47                 ` Erik Bray
2016-11-30 12:29                 ` Corinna Vinschen
2016-11-30 12:36                   ` Corinna Vinschen
2016-11-30 11:36           ` Corinna Vinschen
2016-11-30 11:06       ` Corinna Vinschen
2016-11-30 10:48     ` Corinna Vinschen
2016-11-30 14:49       ` Erik Bray
2016-11-30 15:04         ` Corinna Vinschen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161130122939.GC22541@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).