planning ntpsec 0.9.1 release at about 7pm PST tonight
hmurray at megapathdsl.net
Tue Jan 26 01:16:48 UTC 2016
esr at thyrsus.com said:
> Sure would have been nice if we could have crossported Classic's fix for the
> ^C bug in ntpq, though.
That particular bug isn't a big deal or somebody would have worked on it
The real question is are we going to track fixes from NTP Classic and if so
who, how, when, etc? There were a lot of patches released in the past few
days. I haven't scanned them. I don't think anybody has reviewed all the
changes since the fork.
I looked into the ^C tangle. I'm trying to do it from scratch rather than
blindly copy the new code. Maybe I'll learn enough to understand why the new
code seems so complicated.
It should be simple. The general idea is that the code that calls the
command dispatcher does a setjmp and sets a flag for the ^C signal handler.
If the flag is on, the signal handler does a longjmp to bail from the command.
I put a printf in the top of the signal handler. The problem I'm seeing is
that the ^C handler goes away after the first jump. If it doesn't jump, it
keeps on working.
An additional complication is that readline sets a bunch of signal handlers.
I haven't investigated. Since it isn't mentioned in the man page, I assume
it puts things back the way they were and/or calls the old signal handler.
I tried blindly setting the signal handler again but that didn't fix it.
That's as far as I got before it was time for sleep. Maybe it's masked?
I've spent some time googling but haven't found anything interesting yet.
Are there any obvious gotchas associated with signals and longjmp that I
should know about?
I'm working on Linux/Fedora.
These are my opinions. I hate spam.
More information about the devel