On Fri, Mar 11, 2011 at 3:49 PM, Alexander Kapps <alex.ka...@web.de> wrote:
> On 11.03.2011 03:18, Nobody wrote: > >> On Thu, 10 Mar 2011 23:55:51 +0100, Alexander Kapps wrote: >> >> I think he wants to attach to another process's stdin/stdout and >>>>> read/write from/to them. >>>>> I don't know if this is possible but it would be a great addition for >>>>> psutil. >>>>> >>>> >>>> It's not even a meaningful concept, let alone possible. >>>> >>> >>> Unless I misunderstand something, >>> >> >> You do ... >> > > Many thanks for the correction and lesson (to Grand Edwards too)! > > I still try to digest your explanations. I thought, that processes just do > something like dup()'ing the file descriptors of their terminal but after > some strace experiments, I think that is totally wrong. > Usually, file descriptors are inherited across fork() (and maybe Windows' startprocess), as is the contents of any buffers corresponding to them - so when flushing you can get two copies of the same output, or two copies of the same input. There's no need to dup to just inherit a filedescriptor from a parent process to a child. > I'd like to learn more about this (how processes, their controlling > terminals and the std file descriptors relate) > I'm not sure controlling terminals are that relevant. The standard filedescriptors are just 0, 1, and 2 for stdin, stdout and stderr. They're pretty much like any other filedescriptors, except they tend to be open already when a program starts. Oh, and the buffering might be different from one filedes to another, of course. > Do you know any links to deeper material (tried Google but what I've found > is to shallow) > Check this out; you can pass a filedescriptor through a unix domain socket, though I've never tried it myself in C, let alone Python: http://stackoverflow.com/questions/909064/portable-way-to-pass-file-descriptor-between-different-processes
-- http://mail.python.org/mailman/listinfo/python-list
