Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups: comp.lang.c++
Subject: Re: Solving thundering Herd with glibc...
Date: Fri, 16 May 2025 12:30:03 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 32
Message-ID: <slrn102ebqi.3gnpo.candycanearter07@candydeb.host.invalid>
References: <vue7i0$2btp7$1@dont-email.me>
 <vue9bf$2dodm$2@raubtier-asyl.eternal-september.org>
 <vueanl$2erl6$1@dont-email.me>
 <vufhi7$3jcg6$1@raubtier-asyl.eternal-september.org>
 <1002beu$2htkv$2@dont-email.me> <10042po$306q5$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 May 2025 14:30:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2210600185c98beba6645af6cb60cc18";
	logging-data="3961597"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/osjS18DeBQCPTiYTqS5CsvSF+/9KRr5HOujq7Z1JoHw=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:v344Xal5PdeUyx+zxJdJ7mR/0to=
X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]%
 b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx
 `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e
 ZrQsWJ >|l^I_[pbsIqwoz.WGA]<D

David Brown <david.brown@hesbynett.no> wrote at 06:49 this Thursday (GMT):
> On 14/05/2025 17:05, Vir Campestris wrote:
>> On 25/04/2025 09:37, Bonita Montero wrote:
>>> Am 24.04.2025 um 23:33 schrieb Chris M. Thomasson:
>>>
>>>> "there’s no thundering herd, ever!" because a controlled test didn't 
>>>> "show it" is like saying race conditions do not exist because your 
>>>> code "worked fine this time."? Fair enough?
>>>
>>> Yes, controlled test with 10'000 iterations.
>>> The code is correct and trivial, but too much for you.
>>>
>> Once upon a time I put a race in a bit of code.
>> 
>> It took us 3 years to track down why our customers were reporting 
>> occasional faults :(
>> 
>> (It turned out the trick to reproduce it was a combination of lots of 
>> CPU load and disk transfers not more than once every 30 seconds)
>> 
>
> It's always fun dealing with a bug that only triggers in rare timing 
> situations.  We once had a mistake in a timing table in a program that 
> could sometimes result in intermittent faults in the system if 
> particular events occurred at the same time, on the 30th of September. 
> Finding an issue that occurred at most once per year was a challenge!


If you knew what date the issue was happening on, could you force the
system clock to be on that day?
-- 
user <candycane> is generated from /dev/urandom