Alexey1994 wrote:
No, I don't have a schedule, just a context switch that launch only when needed (some event like alt+tab or lack of data in the pipe)
Ok, so scheduling and context-switching are apparently different concepts.
But regardless, it probably doesn't belong in the piping mechanism.
I was thinking that when you have:
processA | processB | processC
that an efficient way of doing things would be for processA to do it's normal fwrite() which turns into a write() of BUFSIZ, although it may not detect that it is buffered, so it would be line buffered because it is stdout, and thus not be a full BUFSIZ. But we can start to address the situation where the 1-byte nature that you have implemented (as proof of concept I think) can start to be enhanced so that it would at least be line buffered. So it is at the point that write() or similar is called that you have multiple bytes, and the OS needs to determine what to do with them.
At this point, the OS has control, it hasn't wasted any effort doing buffering, and knows that this is a pipe scenario, and is in a position to do a context-switch to processB.
ProcessB would be initiated at this stage, and when it comes to do a read() of BUFSIZ, the data that was presented by ProcessA can be directly copied to satisfy its requirement.
The same "complication" of line buffering vs fully buffered would exist, plus the fact that the BUFSIZ may be different for the different processes (different compiler or compile options or even language).
And then presumably multi-processing/tasking/contexting/threading/whatever buzzword people keep using would sit on top of that. And a scheduler goes in somewhere.