Re: buffering when reading from unnamed pipe with child process

After the fork you have two processes which each get slices of time in which to do some work. That means that the nature of that work is bursty - busy for a while, idle for a while - depending on what else is going on in the machine so for both producer and consumer the processing is in bursts and that is essentially out of the control of the processes. It's not the pipe that is introducing the burstiness through buffering, but it is a fundamental property of preemptive multi tasking operating systems.

You could introduce semaphores or mutexes to lock step the two processes, but then you probably lose the advantage of having two processes anyway.

Update: that might make sense if the OP didn't have a sleep generating output in bursts. See tybalt89's reply below.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Comment on Re: buffering when reading from unnamed pipe with child process

Replies are listed 'Best First'.
Re^2: buffering when reading from unnamed pipe with child process by tybalt89 (Monsignor) on Nov 20, 2020 at 00:38 UTC
Nope. The first buffered read `<$h>` grabs all five of the first sent lines, and leaves the handle empty, thus the delay for the second read. It's not until the 6th line comes in that the program can get to the second read. The usual advice is to not mix buffered and un-buffered I/O, and this code is the perfect example of why. IO::Select operates on unbuffered data while readline is buffered. That's why I used sysread (which is unbuffered) rather than readline. NOTE: Using sysread may get you more than one line at a time (or even partial lines) which is why I added the loop that extracts and deletes one while line at a time.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: buffering when reading from unnamed pipe with child process
by tybalt89 (Monsignor) on Nov 20, 2020 at 00:38 UTC

Nope.

The first buffered read <$h> grabs all five of the first sent lines, and leaves the handle empty, thus the delay for the second read. It's not until the 6th line comes in that the program can get to the second read.

The usual advice is to not mix buffered and un-buffered I/O, and this code is the perfect example of why. IO::Select operates on unbuffered data while readline is buffered.
That's why I used sysread (which is unbuffered) rather than readline.

NOTE: Using sysread may get you more than one line at a time (or even partial lines) which is why I added the loop that extracts and deletes one while line at a time.

[reply]
[d/l]