Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: [PATCH 0/4] Improve delayer (Julien ?LIE)
2. Re: [PATCH 0/4] Improve delayer (Christoph Biedl)
3. Re: tradspool tooken weirdness (Christoph Biedl)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Jan 2024 13:00:04 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: [PATCH 0/4] Improve delayer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Christoph,
>> I'm wondering whether we should not implement a minimal delayed time for a
>> line before being sent, for the script to be even more efficient.
>
> 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.
No need for any alarm I think.
Unless I misunderstand the rule about when the spooled lines are written?
--
Julien ?LIE
??Pour c?l?brer ce jour heureux, buvons un coup, buvons-en deux.??
(Aristophane)
------------------------------
Message: 2
Date: Wed, 17 Jan 2024 21:11:41 +0100
From: Christoph Biedl <[email protected]>
To: [email protected]
Subject: Re: [PATCH 0/4] Improve delayer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
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/
------------------------------
Message: 3
Date: Wed, 17 Jan 2024 21:33:09 +0100
From: Christoph Biedl <[email protected]>
To: [email protected]
Subject: Re: tradspool tooken weirdness
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE wrote...
> Hi Christoph,
> > Heh, was thinking about 64bit article numbers as well ...
> >
> > Major concern is "Is this really needed?". The highest article number I
> > have here has seven digits (in control.cancel, no surprise), and the
> > last number reset was at least 25 years ago. So hitting the 32 bit limit
> > is not going to happen any time soon.
>
> Some users speak about it from time to time. Binary newsgroups are
> certainly the most likely ones to hit the current 2^31 limit first.
According to a message I received in private, some binary groups already
crossed that border some 15 years ago.
[ Clients and 64 bit article numbers ]
> FWIW, the idea would be not to return large article numbers unless the news
> client confirms it can handle them. We discussed a MAXARTNUM capability to
> achieve that in December 2022 in news.software.nntp:
>
> <[email protected]>
> https://groups.google.com/g/news.software.nntp/c/4_KjHu9GlBg
Will read the entire discussion later. Personally, this idea gives me a
bad feeling for introducing some complexity instead for just forcing the
clients to deal it with. But possibly this has already been voiced and
discussed.
> > On the other hand, there's the main lesson from y2k and upcoming
> > y2038: Software will be used for way longer times and at way bigger
> > scale than initially anticipated - therefore adapt early.
>
> As you're speaking about y2038, there's an open bug to support the upcoming
> 64-bit time_t transition for 32-bit archs that some distributions plan to
> do:
> https://github.com/InterNetNews/inn/issues/292
> https://wiki.debian.org/ReleaseGoals/64bit-time
>
> The CAF file header should be converted to use uint64_t instead of time_t
> (as well as size_t and off_t). Otherwise 32-bit system upgraded to 64-bit
> time_t won't be able to retrieve old articles from a timecaf news spool.
Possibly this should indeed be done in a huge batch of fixing 32/64 bit
issues. However, while tempting, my schedule is pretty full, so don't
expect me to work on this any time soon, sorry.
Christoph
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 157, Issue 11
********************************************
