[PATCH 0/4] Improve delayer

[Christoph Biedl]

Julien ÉLIE wrote...

> Hi Christoph,
>
> > Um, do you mean an upper time limit a line may be queued?
>
> No, I was meaning a lower time limit.
> Suppose the delayed time is 60 seconds, and articles are received at time 3,
> 59 and 62 seconds after the start of the timer.
> I am under the impression that when the third article arrives, all of the
> spooled lines (for the 3 articles) are sent.  So the second article has only
> been delayed for 3 seconds, and the last one had no delay at all.  Isn't it
> what happens?
>
> My question was if we couldn't have a minimal time for an article, for
> instance by associating each spooled line to a time, and only write the ones
> that have been delayed enough according to the timer.

Well, things already work quite that way, that's the combination of
$exp and $line store in @queue.

And while doing some extra checks I learned a few bits. Warning, the
output buffering done by delayer can easily cause some confusion.

Good news, a stand-alone test is very easy to do. For better visibility,
I recommend the ts (timestamping) program as it prefixes each input line
with a timestamp.[1] If you don't have it, use cat and a clock instead.

So, your example can be modelled as

    $ ( sleep 3 ; echo 'art1' ; sleep 56 ; echo 'art2' ; sleep 3 ; echo 'art3' ) | ts -s
    00:00:03 art1
    00:00:59 art2
    00:01:02 art3

Adding delayer. Also, enhanced a bit to demontrace the end of input
problem, line breaks added for readability.

    $ (
        sleep 3 ; echo 'art1' ;
        sleep 56 ; echo 'art2' ;
        sleep 3 ; echo 'art3' ;
        sleep 58 ; echo 'EOF'
    ) | perl contrib/delayer.in --delay 60 --no-buffered -- ts -s
    00:01:03 art1
    00:01:59 art2
    00:02:00 art3
    00:02:00 EOF

The first two lines are delayed by 60 seconds as desired, the third not
because everything is flushed at end of input.


So, except for end of input, delayer does the right thing: Lines are
delayed right by the given amount of seconds. (If you're pendantic: As
the time value is an integer, the delay might be up to a second shorter
or longer, and those who really care about it - I don't - should add
"use Time::HiRes qw<time>;".)


Also, it's not necessary to have another input to trigger output, that
was a misunterstanding on my side. So please drop the lines

+Still a line is not sent to output until another line is read from the
+input.

from the patch. Use the test above with a delay of 10 to see it's just
not true.

    Christoph

[1] Part of Debian's moreutils, source also available at
    https://sources.debian.org/src/moreutils/0.67-1/ts/