Re: A bit of PG archeology uncovers an interesting Linux/Unix factoid

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A bit of PG archeology uncovers an interesting Linux/Unix factoid
Date: 2016-02-16 02:12:36
Message-ID: 56C28594.2030507@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02/15/16 20:03, Greg Stark wrote:
> On Tue, Feb 16, 2016 at 12:51 AM, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>> If the calling process subsequently waits for its
>> children, and the process has no unwaited for children that were
>> transformed into zombie processes, it will block until all of its
>> children terminate, and wait(), wait3(), waitid() and waitpid() will
>> fail and set errno to [ECHILD].

> And actually looking at that documentation it's not clear to me why
> it's the case. I would have expected system to immediately call
> waitpid after the fork and unless the subprocess was very quick that
> should be sufficient to get the exit code. One might even imagine
> having system intentionally have some kind interlock to ensure that
> the parent has called waitpid before the child execs the shell.

Doesn't the wording suggest that even if the parent is fast enough
to call waitpid before the child exits, waitpid will only block until
the child terminates and then say ECHILD anyway?

I wouldn't be surprised if they specified it that way to avoid creating
a race condition where you would *sometimes* think it was doing what you
wanted.

Agree that the language for ECHILD in system(3) doesn't clearly reflect that
in the "status ... is no longer available" description it gives for ECHILD.

-Chap

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh berkus 2016-02-16 02:41:16 Re: Declarative partitioning
Previous Message Merlin Moncure 2016-02-16 02:09:16 Re: Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?