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

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: A bit of PG archeology uncovers an interesting Linux/Unix factoid
Дата
Msg-id CAM-w4HMtJZLHS7tMOxRoSNhAXvfNS1etL-qotcHy8r8cqz1bCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A bit of PG archeology uncovers an interesting Linux/Unix factoid  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: A bit of PG archeology uncovers an interesting Linux/Unix factoid  (Chapman Flack <chap@anastigmatix.net>)
Список pgsql-hackers
On Tue, Feb 16, 2016 at 12:51 AM, Chapman Flack <chap@anastigmatix.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].

Sure, but I don't see anything saying system() should be expected to
not handle this situation. At least there's nothing in the system.3
man page that says it should be expected to always return an error if
SIGCHILD is ignored.

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.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: postgres_fdw vs. force_parallel_mode on ppc
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.