sys._exit()

[Donn Cave]

Quoth David Bolen <db3l at fitlinxx.com>:
| Donn Cave <donn at drizzle.com> writes:
|
|> Well, note that the fork runs in a separate address space and can't
|> modify the parent's state.
|
| No, but system resources like file handles are just copied literally
| into the client's address space (not 'dup'd).  So if the client were
| to close a common handle, the parent's handle would then become
| invalid.  (Thus the typical create pipe, fork, and then have
| parent/child carefully close opposite ends of the pipe handles before
| using the other set of handles).

I am not clear on what you mean here.  Your parenthetic observation
about fork and pipe is right, but I would say it shows that the parent
is safe from the child:  "using the other set of handles" means each
reads from the descriptors closed by the other - which obviously didn't
make the descriptors invalid!  A fork certainly can't close anything
in its parent.

Actually the point of that pipe closing ritual will be vaguely familiar
to Python programmers, because it's working with a reference counting
feature in the kernel.  The device close doesn't happen until all the
descriptors close, and that means dups and fork copies.  Normal pipe
usage depends on the pipe device to close when the writer is through,
yielding end of file for the reader, and that can't happen if the
reader has accidentally kept its own write end descriptor copy open.
So in this sense of device finalization, yes, the parent could get
end of file or something.

But posix._exit() will eventually close whatever descriptors were
open in the fork, that can't be helped.  I will stick with my comments
about process-buffered output and trapping SystemExit.

	Donn Cave, donn at drizzle.com