Re: ntpq mrulist bug

2019-11-20 Thread Eric S. Raymond via devel
Hal Murray : > Part of the problem is that there is a lot of cruft in that area. For > example, grep for CERR_ > There is a clump of signals defined as part of a ControlSession, none are > ever > raised, a few are caught. Looks like somebody decided to rename things to > SERR and never got ar

Re: ntpq mrulist bug

2019-11-20 Thread Ian Bruene via devel
On 11/20/19 5:44 PM, Hal Murray via devel wrote: Part of the problem is that there is a lot of cruft in that area. For example, grep for CERR_ There is a clump of signals defined as part of a ControlSession, none are ever raised, a few are caught. Looks like somebody decided to rename things

Re: ntpq mrulist bug

2019-11-20 Thread Hal Murray via devel
> I don't think I know yet. I lean towards an incremental fix along the lines > you describe, but it's also possible that there's a serious design flaw that > merits a rewrite. The 20,000 ft view looks reasonable, but I think the use of signals is unreasonably complicating the control flow.

Re: ntpq mrulist bug

2019-11-20 Thread Eric S. Raymond via devel
Hal Murray via devel : > I know what's going wrong, but I'm not enough of a python geek to see a clean > fix. > > The basic idea is that the client sends a request and the server sends back a > clump of packets. The client specifies the max clump size. What's happening > is that at least one