Unqualified thoughts

I think it would be a not-very-good idea to add a bottleneck er mutex to threading NTPsec, Linux worked hard to kill off their global lock IIRC. A 24 block byte should suffice for the client-supplied data to the NTPv3/4 server threads, NTPv2 would probably need the same with perhaps a dozen bytes

Fw: New Defects reported by Coverity Scan for ntpsec

Yo All! New coverity defects in ntpd. See below. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid es

Re: Unqualified thoughts

Unqualified thoughts said: > I think it would be a not-very-good idea to add a bottleneck er mutex to > threading NTPsec, Linux worked hard to kill off their global lock IIRC. The current code is single threaded so adding a global lock is just to preserve correctness until we fix the code to u

Re: Fw: New Defects reported by Coverity Scan for ntpsec

On Mon, Jan 25, 2021 at 12:03 PM Gary E. Miller via devel wrote: > Yo All! > > New coverity defects in ntpd. See below. > Date: Sun, 24 Jan 2021 07:29:27 + (UTC) > From: scan-ad...@coverity.com > To: g...@rellim.com > Subject: New Defects reported by Coverity Scan for ntpsec > > 4 new d