SIGCHLD and the "wait" system call
Andrew Gierth
>>>>> "Soumyabrata" == Soumyabrata Bhattacharya <sou...@marconi.ih.lucent.com>
writes:
Soumyabrata> Hi,
Soumyabrata> This is a question I had regarding the behavior of the
Soumyabrata> "wait" system call usually issued by a parent process to
Soumyabrata> wait for a child process to exit.
Soumyabrata> If the parent process has *not* installed any handler
Soumyabrata> for the signal SIGCHLD, the return code of "wait"
Soumyabrata> indicates the pid of the child (when the child
Soumyabrata> terminates). But if the parent has a handler installed
Soumyabrata> for SIGCHLD, wait returns -1 (upon child's exit) setting
Soumyabrata> errno to EINTR. This is kind of in line with the
Soumyabrata> philosophy of "system call interrupted upon receipt of a
Soumyabrata> signal", but would it not be nice if in this case "wait"
Soumyabrata> would still return the child's pid?
No. That would be inconsistent. What happens if the SIGCHLD handler calls
wait()?
In practice, you shouldn't be blocking in wait() or waitpid() with
SIGCHLD both caught and unblocked. Either you want to handle terminated
children by signals, in which case you call waitpid() in your SIGCHLD
handler, or you are handling terminated children in your mainline code
using wait() et. al., in which case you shouldn't be catching SIGCHLD
at all.
In the case where you *are* catching SIGCHLD, but need to wait for a
specific process, then you either block SIGCHLD and use waitpid(), or
use pause() or sigsuspend() and have your signal handler indicate when
the desired process has been handled.
--
Andrew.
comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>
Soumyabrata Bhattacharya
Hi,
This is a question I had regarding the behavior of the "wait"
system call usually issued by a parent process to wait for
a child process to exit.
If the parent process has *not* installed any handler for the
signal SIGCHLD, the return code of "wait" indicates the pid of
the child (when the child terminates). But if the parent has
a handler installed for SIGCHLD, wait returns -1 (upon child's
exit) setting errno to EINTR. This is kind of in line with the
philosophy of "system call interrupted upon receipt of a signal",
but would it not be nice if in this case "wait" would still
return the child's pid?
Also, it is stated that the default action of SIGCHLD is to ignore
the signal which is same as setting it to SIG_IGN. But setting
SIGCHLD to SIG_IGN again causes wait to behave differently: the
children processes are never made zombies and when wait returns it
returns with a return code of -1 and errno set to ECHLD. Is it
not somewhat in conflict with the statement "default disposition
is same as ignoring the signal"?
Thanks in anticipation of any reply.
-Soumya
Geoff Clare
James Youngman <JYou...@vggas.com> writes:
> Ingo> On most systems I ran the program (HP-UX, Solaris, ULTRIX),
> Ingo> scanf() is aborted, if SIGUSR2 is received while scanf() is
> Ingo> waiting for input.
> Ingo> I expected, that scanf() ....
> Ingo> would continue after the end of the signal handler.
> Ingo> I found only LINUX working this way.
>After a signal handler has been invoked for a signal (that is, the
>signal is "delivered"), the system call is ALWAYS interrupted (usually
>producing errno=EINTR, except for "pause" and maybe "sigsuspend"
>IIRC). Some systems provide SA_RESTART to provicde the old BSD-like
>semantics, but that wasn't what you were asking.
This is true for signal handlers installed with sigaction(). It
sounds to me like Ingo was using signal(), in which case some systems
will restart interrupted system calls and some won't.
If Ingo used sigaction() without SA_RESTART on Linux, and the scanf()
was not interrupted, then that is a bug in Linux.
>However the <stdio.h> (that is, scanf()) implementation may or may not
>choose to REPEAT the system call. This is a quality-of-implementatino
>issue for the C library.
No. POSIX requires that stdio functions return an error indication
when an underlying I/O operation fails, with errno set to the value
that read() or write() (or lseek()) would have set for the same
error condition. (I'm not sure if this only applies to the error
conditions defined by POSIX, but EINTR is one of those, so it is
true for the case in point.)
This should not be confused with the case of read() or write() returning
less than the number of bytes requested (but greater than zero). In this
case the stdio functions should loop on read() or write() until either
all the data is read/written or an I/O error (or EOF) occurs.
--
Geoff Clare <g...@root.co.uk>
UniSoft Limited, London, England.
Ingo Phleps
Thank You for all the answers I got.
On 27 Aug 1997, Boyd Roberts wrote:
> As Dennis Ritchie said, signals were intended to kill processes.
But hence it follows a new question:
Which mechanism could (should) be used by a process to handle
asynchronous events (i.e. "interrupts")?
In detail:
I'm considering to handle service requests of devices (SRQ's of
GPIB devices, OS is HP-UX) as asynchronous events, not by polling.
In these applications, aborting system calls is not wanted and
blocking signals for *every* system call is no good solution.
I know the risk of applications using asynchronous events, but
in some applications, it is advantageous.
I'm sorry, my example to describe the background of my the first
question, more turned away from the real problem than it helped
to understand it.
Thanks for hints
Ingo
-------------------------------------------------------------------------------
Ingo Phleps e-mail: ingo....@bk.bosch.de
Bosch Telecom GmbH Phone: (+49) 7191/13-3663
Dep. UC-RA/FRT FAX: (+49) 7191/13-3620
Gerberstr. 33
D-71522 Backnang
Germany
Bruce Ediger
Ingo Phleps <ingo....@bk.bosch.de> wrote:
>Which mechanism could (should) be used by a process to handle
>asynchronous events (i.e. "interrupts")?
"Threads". Lots of 'em, some of 'em on my back.
Actually, wouldn't the Mach model make more sense? That is, you have
some method of communicating with the kernel. In Mach, this is a "port",
a reliable queue of typed messages. One of these ports in a task is
designated the "exception port". The kernel sends messages to the task,
which can either choose to ignore the messages, have a thread read them,
or even pass the port off to some other task to have it get the exception
messages. I believe that the kernel can "poison" messages so that the
task and all its threads get shut down no matter what.
The Mach paper on all this is at:
http://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/abstracts/exception.html
--
For your harvesting consideration, punk spammers:
rhu...@fcc.gov jqu...@fcc.gov sn...@fcc.gov rch...@fcc.gov
cust...@email.usps.gov