public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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