Support for process management in terms of child/parent processinteraction - Programmer

This is a discussion on Support for process management in terms of child/parent processinteraction - Programmer ; WA> On Windows I use multiple processes which use socket IPC. The WA> only downside is Windows has categorically inferior support for WA> process management in terms of child/parent process interaction. Untrue. (This is not least in part because Windows ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Support for process management in terms of child/parent processinteraction

  1. Support for process management in terms of child/parent processinteraction

    WA> On Windows I use multiple processes which use socket IPC. The
    WA> only downside is Windows has categorically inferior support for
    WA> process management in terms of child/parent process interaction.

    Untrue. (This is not least in part because Windows NT natively has
    all of the requisite mechanism for providing the POSIX API functions
    for process handling. It does, after all, have a POSIX subsystem.)
    Indeed, native facilities aside, Win32 is actually superior in several
    areas. For example: In this very newsgroup a mere three days ago
    someone was asking how a child process could receive notification that
    its parent process had terminated. That's tricky to do in Unix, and
    the best solution if one really does want this is usually to change
    the application architecture, either reversing the roles of parent and
    child or waiting for IPC mechanisms to be closed rather than for
    processes to terminate. On Win32, in contrast, the mechanism for
    waiting for process termination is not arbitrarily constrained by
    parent-child relationships, and is more coherent and uniform than on
    Unix. To wait for one's parent process, or indeed for any other
    process that one didn't create onesself and so doesn't already have an
    open handle for, to terminate, one obtains the target process ID in
    some fashion (such as via the ToolHelp API) and then simply calls
    OpenProcess() specifying the SYNCHRONIZE access right (which will of
    course fail if the access control list on the process does not grant
    one that right) and the universal wait functions WaitForSingleObject()/
    WaitForMultipleObjects() (and then closes the handle, of course).

  2. Re: Support for process management in terms of child/parent processinteraction

    J de Boyne Pollard wrote:
    > WA> On Windows I use multiple processes which use socket IPC. The
    > WA> only downside is Windows has categorically inferior support for
    > WA> process management in terms of child/parent process interaction.
    >
    > Untrue.


    [counter-example snipped]

    Though your example makes sense, I don't think it's directly on point.
    In fact I think it goes some way to illustrate the previous poster's
    point. With specific regard to parent/child interaction, Windows is
    weaker precisely because it deliberately chooses to suppress the
    distinction.

    The way I like to explain it is this: Unix is *mammalian* in that
    parents gestate a child (by "forking"!) which looks much like them and
    the relationship lasts throughout their life. Granted, the metaphor
    breaks down somewhat when the parent waits for the child to die. By
    contrast, Windows is *reptilian* because processes spawn other processes
    but never look back and there is no special filial relationship once the
    new process is born.

    Your point that any process can wait for any other (or do anything with
    any other, permissions allowing, once it digs up the process handle) is
    illustrative of this. Yes, Windows has useful capabilities that Unix
    doesn't. But in the specific area of parent/child structure, Unix has it
    and Windows, by design, does not. None of which is to say that Unix
    couldn't stand to add a few features, possibly even (gasp) learned from
    Windows.

    All this can be summarized and symbolized by getppid(), which is the way
    to say "who's my daddy?" Unix has it, Windows doesn't[*]. Not because it
    couldn't but because the process model doesn't care.

    HT
    [*] And yes, there are ways of mocking up a getppid for Windows. I speak
    as one who has done so. But the lack is still a clue to the Windows
    architecture.

  3. Support for process management in terms of child/parent processinteraction

    WA> On Windows I use multiple processes which use socket IPC. The
    WA> only downside is Windows has categorically inferior support for
    WA> process management in terms of child/parent process interaction.

    JdeBP> Untrue.

    HT> [counter-example snipped]

    You should have read the part that you excised.

    HT> Though your example makes sense, I don't think it's
    HT> directly on point. In fact I think it goes some way to
    HT> illustrate the previous poster's point. With specific
    HT> regard to parent/child interaction, Windows is weaker
    HT> precisely because it deliberately chooses to suppress
    HT> the distinction. [...] in the specific area of parent/child
    HT> structure, Unix has it and Windows, by design, does
    HT> not.

    .... except that it does no such thing, so your whole argument, based
    upon that premise, falls apart. There's a parent process ID field in
    the EPROCESS structure of a Windows NT process (at offset 0x1c8) just
    as there are a parent process ID fields in the process structures of
    processes on Unices. It's not suppressed at all. Windows NT has
    exactly the structure that you are talking about. As I wrote in the
    text that you should have read, Windows NT has all of the requisite
    mechanism for providing the POSIX API functions for process handling.
    It has to, in order to support its POSIX subsystem. This includes
    maintaining parent process IDs for every process.

    This whole notion that "Windows NT doesn't have POSIX parent-child
    relationships for processes." is a folk myth; highly prevalent on
    Usenet and on WWW discussion fora, but quite untrue. Beware of basing
    arguments upon it.

    HT> None of which is to say that Unix couldn't stand to add
    HT> a few features, possibly even (gasp) learned from Windows.

    The ability to inform the kernel about the intended sequential/random
    access use of a file description (i.e. FILE_FLAG_RANDOM_ACCESS and
    FILE_FLAG_SEQUENTIAL_SCAN) comes immediately to mind.

  4. Re: Support for process management in terms of child/parent processinteraction

    J de Boyne Pollard wrote:
    > HT> [counter-example snipped]
    >
    > You should have read the part that you excised.


    I did.

    > ... except that it does no such thing, so your whole argument, based
    > upon that premise, falls apart. There's a parent process ID field in
    > the EPROCESS structure of a Windows NT process (at offset 0x1c8)


    Does it have a native API for getting the parent process id, aka
    getppid? If it's not part of the documented API it doesn't count.

    If I am a parent process, what are the differences in my relationships
    with two other processes, only one of which is my child? Am I informed
    when my child dies, for instance?

    HT

  5. Re: Support for process management in terms of child/parent process interaction

    Henry Townsend writes:
    >J de Boyne Pollard wrote:
    >> WA> On Windows I use multiple processes which use socket IPC. The
    >> WA> only downside is Windows has categorically inferior support for
    >> WA> process management in terms of child/parent process interaction.
    >>
    >> Untrue.

    >
    >[counter-example snipped]
    >
    > None of which is to say that Unix
    >couldn't stand to add a few features, possibly even (gasp) learned from
    >Windows.


    Well, considering that particular windows feature derives from VMS
    (and likely has precendents in Multics, MVS, MCP et. al.), it's unclear
    what new OS capabilities one can learn from windows.

    scott

+ Reply to Thread