This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Retrieving per-process environment block?

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



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

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]