>> how many - and which - use cases would break if all readers going >> away produced an immediate SIGPIPE to anyone with the write end >> still open (ie, not waiting for anything to be written)? > Well, anything that, at the end, does something uninteresting > (regarding its output) that takes a long time.
Not quite. Anything that does that and is piped into something which exits before the "something" finishes. But I was wondering if anyone had any specific examples. Do you have any specific use cases which fit that description? I've got lots for TCP connections (I often use TCP connections with one direction shut down but the other still flowing), but I haven't come up with any for pipes. > But whatever, POSIX wouldn't allow that behaviour, would it? POSIX cannot control what people choose to run on their machines. If this behaviour proves to be more useful, useful enough to be popular, it's worth keeping regardless. Standards exist to serve people, not to straitjacket them, after all. If nobody can come up with anything specific, or only cases rare and/or fixable enough, I think it might be worth the experiment. (I'm not sure how to *find* all the processes with the write end open, but I'm sure that can be solved, by scanning all processes if necessary, and if that proves a performance problem then some data structure can be invented to solve it.) That's not to say that I think "the experiment" means putting it into NetBSD's main tree. I'm talking about someone making the changes, trying them, and if they work for one person, passing them around to see if they get popular. If the result is popular enough, then it might be worth considering it for NetBSD's main line. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
