Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Sep 1997 21:10:52 -0700 (PDT)
From:      "Jamil J. Weatherbee" <jamil@counterintelligence.ml.org>
To:        David Greenman <dg@root.com>
Cc:        Greg Lehey <grog@lemis.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: SIGCLD 
Message-ID:  <Pine.BSF.3.96.970901210553.4103B-100000@counterintelligence.ml.org>
In-Reply-To: <199709020354.UAA17302@implode.root.com>

next in thread | previous in thread | raw e-mail | index | archive | help

>    Yes, there is a difference. SIGCHLD signal delivery isn't reliable, so if
> a SIGCHLD is missed, it is possible that more than one process needs to be
> reaped. The first form will only reap on child, while the second form reaps
> all of them. You want to use the second form.

So, in the capacity that I plan on using the non zombieing children is
demonstrated below -- I don't care which order the lines are written in
(will not be a regular file, rather a socket descriptor) just that i don't
end up with a collision of the two -- as long as I am using the low level
read/write calls (as opposed to stream io), can I be certain that the
pieces of data are delivered one after the other(in any order), is this a
result of the fact that the kernel is single threaded? Will this always
work even in future (possibly multithreaded) kernels?

---------------------------------------------------------------
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <sys/stat.h>

void die (int sig)
{
  int status;
  while (wait3 (&status, WNOHANG, (struct rusage *) NULL)>0);
}

void main (void)
{
  char msgpar[] = "the parents big long insignificant message\n";
  char msgcld[] = "childs string that really says nor means anything\n";

  int fd = open ("garbage",O_CREAT|O_RDWR,S_IRUSR|S_IWUSR);
  signal (SIGCHLD, die);
  if (fork())
   {
      write (fd, msgpar, sizeof(msgpar)-1);
      exit (0);
   }

  write (fd, msgcld, sizeof(msgcld)-1);
}








Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970901210553.4103B-100000>