Once less has displayed the first screen full, it stops reading the pipe and waits for instructions from the keyboard. The pipe fills and won't accept anymore from the producer, so it blocks on the write until the pipe empties. Which it won't until you hit the space bar or similar.

buf.pl uses a shared queue as a buffer between two threads, The read thread just keeps reading and pushing to the queue. The write thread reads from that queue and writes to the pipe. Because the two are asynchronous, when the write thread blocks because the pipe to less is full, the reader just carries on filling up memory until the producer finishes.

The downside is that if the producer produces sufficient output, the perl process will eventually run out of memory and die.

There it is, thanks. I was lost by the disconnect between the two facts: 1. 'less stops after one screen' and 2. 'perl produces more than one screenful before it pauses'.

What is buf(.pl) doing that prevents 'less' from stopping it?

Nothing. buf's output thread is still blocking at the same spot as the producer would without buf.

less stops reading when it has enough to display what it needs to display. The producer doesn't know or care when that happens, so it keeps adding to the pipe until it fills up. Trying to add more to the pipe, the producer blocks until less starts emptying it.

buf reads all that it can as fast as it can. That's likely to be faster than the producer can produce output, so the pipe from the producer never fills, so the producer never blocks. buf keeps the lines it read in a Queue from where the writer will fetch them when it unblocks.