Hi Ken,
discard.c also has some non-portable code:
And it's called on the streams that post uses to talk to its smtp
server:
kill (sm_child, SIGKILL);
discard (sm_rfp);
discard (sm_wfp);
The discard()'s after killing the child process seem unnecessary to
me.
I am wondering ... maybe the point of discard() is to prevent a
SIGPIPE? If those streams try to write on the process after they've
closed, that is what will happen, right? At the very least that would
happen when exit() is called.
Yes, if a FILE-stream has data for writing that's buffered and write(2)s
it down the underlying file descriptor that's closed by the reader then
a SIGPIPE results. And that'll happen on exit(3) if not before.
Abusing python by knowing it uses stdio's FILE-streams and meddles with
the `terminate process' default action of SIGPIPE,
$ ltrace -e fwrite python -c 'import time; time.sleep(1); print "foo\n"' |
> (exec 0<&-; sleep 2)
fwrite("foo\n", 1, 4, 0x7f063030b780) = 4
--- SIGPIPE (Broken pipe) ---
close failed in file object destructor:
Error in sys.excepthook:
Original exception was:
+++ exited (status 0) +++
$
The fwrite's fine, nothing attempts to go down the pipe until Python
exits; it then catches the SIGPIPE.
I see fpurge() is not part of POSIX, so we can't rely on it. So I'm
not sure what to do; maybe the correct solution is to block SIGPIPE
and close those filehandles?
Or ignore SIGPIPE whilst fclose-ing the FILE-streams?
I've lost the original context. Must the child be killed? Could it
exit when the pipe it's reading from the parent is closed instead? That
still leaves the issue of data sitting in the output buffer when the
parent desires child's death and fcloses the FILE-stream.
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers