From: "Michael Kerrisk" <mtk-lkml@gmx.net>
To: Roland McGrath <roland@redhat.com>
Cc: torvalds@osdl.org, akpm@osdl.org, drepper@redhat.com,
linux-kernel@vger.kernel.org, michael.kerrisk@gmx.net
Subject: Re: [PATCH] waitid system call
Date: Fri, 20 Aug 2004 08:00:52 +0200 (MEST) [thread overview]
Message-ID: <28571.1092981652@www22.gmx.net> (raw)
In-Reply-To: 200408192053.i7JKrE9g024895@magilla.sf.frob.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2837 bytes --]
Roland,
> > all seems well, with one possible doubt. How can one
> > distinguish "no children to wait for case" and the "child
> > successfully waited for case" when using WNOHANG?
>
> This is something I did consider in detail, though I overlooked
> commenting
> on it. The POSIX wording on this is not entirely unambiguous. What it
> does say is, "If waitid() returns because a child process was found
> [...],
> then the structure pointed to by infop shall be filled in by the system
> [...]" It does not say that *infop is written in any other case. So, I
> think a POSIX-compliant application must not assume that it will be.
Agreed. But nor does it prohibit it. More below.
> Given that specification, I made the system call do just what it says and
> no more. For a WNOHANG return without a child, it doesn't touch the
> structure.
>
> The tst-waitid program intends to be POSIX-compliant (in its use of
> waitid), and so I wrote it to zero the si_signo field before the call and
> check whether it got set to SIGCHLD or not. The POSIX specification for
> waitid specifically requires that si_signo be set to SIGCHLD when the
> siginfo_t is filled in. Taking the standard as a whole, you can also
> conclude that it requires that si_pid be filled in and not zero. So that
> is also a reasonable test--if you zeroed the structure (or at least the
> field you want to test) before the waitid call.
>
> I think one could even construe the POSIX wording to mean that a WNOHANG
> return-without-child should not touch the structure at all. However, I
> would not argue for that and say Solaris should not zero si_pid here.
That would certainly strain my powers of interpretation ;-).
Anyway, as you noted recently in another thread, sometimes
improvements on POSIX are worth having. To that, I'd add:
"especially if other systems also have them".
I did some more investigaton and testing:
-- Tru64 5.1 behaves like Solaris 8 -- si_pid == 0 for
the WNOHANG with no children case.
-- HP-UX 11 is different -- not even POSIX compliant. It
returns -1 with ECHILD in this scenario.
-- According to the man pages, waitid() is also present on
Irix 6.5 and UnixWare 7, but I don't have access to
those systems to run a test (my earlier test program
would be sufficient to test on those systems).
So, discounting the non-compliant HP-UX, on other
implementations we have 2 out of 2 for the "si_pid == 0"
behavior. (I will see if I can get access to other
systems for further testing.) So, how about
reconsidering the approach for Linux?
Cheers,
Michael
PS Perhaps it would be worth investigating this further on
the Austin list? I'm happy to start a thread there.
--
NEU: Bis zu 10 GB Speicher für e-mails & Dateien!
1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail
next prev parent reply other threads:[~2004-08-20 6:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-15 23:03 [PATCH] waitid system call Roland McGrath
2004-08-16 5:40 ` Roland McGrath
2004-08-16 17:15 ` Michael Kerrisk
2004-08-16 21:12 ` Roland McGrath
2004-08-19 17:20 ` Michael Kerrisk
2004-08-19 20:53 ` Roland McGrath
2004-08-20 6:00 ` Michael Kerrisk [this message]
2004-08-20 9:02 ` Michael Kerrisk
2004-08-20 20:04 ` Roland McGrath
2004-08-24 11:51 ` Michael Kerrisk
2004-08-31 6:04 ` Roland McGrath
2004-08-31 6:26 ` Jakub Jelinek
2004-08-31 6:37 ` Roland McGrath
2004-08-31 6:40 ` Andrew Morton
2004-08-31 15:53 ` Bill Davidsen
2004-08-31 18:26 ` Linus Torvalds
2004-08-31 23:51 ` Roland McGrath
2004-09-01 11:31 ` Michael Kerrisk
2004-08-31 7:22 ` Michael Kerrisk
2004-08-22 8:53 ` Tonnerre
[not found] <2tCiy-8pK-13@gated-at.bofh.it>
2004-08-16 0:03 ` Andi Kleen
2004-08-16 2:10 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28571.1092981652@www22.gmx.net \
--to=mtk-lkml@gmx.net \
--cc=akpm@osdl.org \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.kerrisk@gmx.net \
--cc=roland@redhat.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox