using fork and wait reliably w/signals
From: Eric Taylor (et2_at_rocketship1.com)
Date: 10/26/05
- Next message: Kasper Dupont: "Re: using fork and wait reliably w/signals"
- Previous message: Tauno Voipio: "Re: need help in developing a secure encrypted filesystem for a usb pendrive"
- Next in thread: Kasper Dupont: "Re: using fork and wait reliably w/signals"
- Reply: Kasper Dupont: "Re: using fork and wait reliably w/signals"
- Reply: Chris Friesen: "Re: using fork and wait reliably w/signals"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 26 Oct 2005 10:17:03 -0700
I am considering a suggestion to use fork to write out
a large buffer (order of gigabytes) while the parent
continues running.
In reading Steven’s Unix programming book, I see a
discussion about unreliable signals and also about
interrupted system calls. Does all this still apply to
Linux nowadays?
I also have 3 more specific questions:
------------------
1. Must I wait on the child at some point knowing it
will eventually exit (in a few minutes once the buffer
has been written to disk)?
------------------
I want both the parent and child to proceed on their
own, until the child exits. At some time later, I will
be repeating this operation, and I don’t ever want to
start the next child until I am certain the last one
has finished and exited.
One approach I was thinking about was to do a wait
–before- the fork. I would think (hope?) that the first
wait, before I ever forked would simply come back
immediately. Ditto on the second time through, if the
child had exited from the last fork. And if it had not
yet finished, I would then wait. Does this logic sound
correct? Using this approach, I would not need to
enable a signal which I discuss in the next question.
Does the child really go away on the exit, or does it
linger until the wait is done from the parent. I'm
wondering about the copy on write. As I understand
it, it's implemented by setting a read-only flag
on the pages in the parent, so it can detect modifications
by the parent, at which time it makes the copy for the
child. But, when the child exits, will this read-only
flag (if this is the true mechanism) be reset on the
parent pages, so it won't have to go through this logic
any longer?
------------------
2. Is there a way to catch a child exit signal and be
certain to not disturb the parent, which might be in
the middle of some system call?
------------------
Does linux queue up signals so that they can be caught
only at the end of a system call? Or does it interrupt
the system call and cause it to fail expecting the user
to repeat the system call. Or does it attempt to
continue the interupted system call.
I’m afraid that there’s probably some system calls in
this program that do not check for this possibility. I
can’t take the risk and I don’t even have all the
source code to fix it if it is the case. This program
when written never expected to be interrupted.
------------------
3. What if the parent was to call “system” while the child
was still running?
------------------
Suppose I choose to catch a signal (SIGCHLD) to keep
track of when the child exits. Will a call to system
then also cause a signal in the parent when done? Will
it interfere with the wait on the child? Would I need
to do a waitpid instead?
I see a discussion on SIGCHLD and SIGCLD in the
Steven’s book. Which would I use?
- Next message: Kasper Dupont: "Re: using fork and wait reliably w/signals"
- Previous message: Tauno Voipio: "Re: need help in developing a secure encrypted filesystem for a usb pendrive"
- Next in thread: Kasper Dupont: "Re: using fork and wait reliably w/signals"
- Reply: Kasper Dupont: "Re: using fork and wait reliably w/signals"
- Reply: Chris Friesen: "Re: using fork and wait reliably w/signals"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
