planning ntpsec 0.9.1 release at about 7pm PST tonight

[Hal Murray]

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 
sooner.

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.