5 ms·
I wonder how much stuff breaks if you actually change the pipe size. I bet there’s a lot of assumptions kicking around.
by thedance 7y ago
I wonder how much stuff breaks if you actually change the pipe size. I bet there’s a lot of assumptions kicking around.
- jandrese 7y agoThe vast majority of shell script writers don't know or care what the pipe size is. The tools they are using treat them as just one solid stream of data. There's not much to break.
- thedance 7y agoI meant in the kernel. Like if I hooked up a fuzzer and just started swinging the pipe size around.
- jschwartzi 7y agoConsidering there's a semi-contiguous allocation in the kernel I bet you'd find some interesting bugs that way. I don't think very many people mess with the pipe sizes other than to tune to a multiple of the input/output block size for the application. And if you're trying to maximize throughput you're likely to reach your optimum block count long before you start blowing out buffers. Actually, come to think of it named pipes would be another good place to fuzz.
- cat199 7y agothe shell isn't the only user of pipe(2) - that said, since you can't count on fixed scheduling on either end, most things likely will handle things okay
- barrkel 7y agoUnless there's a dialog going on, it shouldn't matter a great deal. But it's easy to mess up a dialog (having a conversation with both stdin and stdout).
- duskwuff 7y agoVery little. The Linux default changed from 4 KB to 64 KB in 2.6.11, and the macOS XNU kernel will actually adjust pipe sizes dynamically based on the size of writes and system memory pressure.