[ntp:hackers] ntp and signalled IO

Harlan Stenn stenn at ntp.isc.org
Tue Apr 18 09:16:54 UTC 2006


> In message <20060418075908.CBEA939B7D at ntp1.ntp.isc.org>, Harlan Stenn writes:
> 
> >The recvbuf fixes are apparently not safe with respect to signalled IO,
> >in part because we seem to be doing "too much work" in the signal handlers.
> 
> Apart from setting (some kinds of) variable, practically nothing is
> safe in a signal handler.

I agree, and that's all I do in signal handlers that I write.

> >I was thinking that we should disable signalled I/O in general, unless
> >somebody has a Really Good Reason why we should continue to support it.
> 
> I fully agree.
> 
> I will argue the PPS-API has made SIGIO support obsolete.  It is cheaper
> in time to buy a PC and install an OS that supports PPS-API than it is
> to get all the magic right to make SIGIO work on an antique platform.

We currently (try and) support SIGPOLL and SIGIO, as appropriate.

> >I am also assuming that sometime after 4.2.2 is released (which will
> >probably now be in a bit over a week, as Danny thinks he'll have a
> >proper fix for the Windows issue with recvbuff in a day or so) we can
> >convert to something like ISC's eventlib code and rewrite the loop code
> >(which will hopefully solve the problems we now have and also eliminate
> >the need for signalled IO).
> 
> As you know I've written my "NTPns" daemon around ISC's eventlib so
> I have been through that bit already and can only warmly recommend it.

I'm not entirely certain how you meant that last bit - you could mean
either:

- you have only good things to say about it
- on a scale of 0(cold/bad) to 10(hot/great) you give it a 6 or a 7

Separately, eventlib seems to use select()/pselect().  I gather
alternatives can include /dev/poll, kqueue(2), and epoll(4) (just to
name some).  How important is it to support some of these other
mechanisms?

> I would caution though, that it might be a lot better idea to start
> from scratch and pull code over in bits and pieces, than it would
> be to try to do a heart transplant on the code in its current
> state.
> 
> So how about we start NTPD 5.x for this and leave 4.x intact ?
>
> That way we can support and maintain the 4.2 branch in parallel
> with the 5.x work.

Let's leave the number out of it for now.  We can easily support
multiple development repositories if we wish, although I suspect that
Dave will want to focus his efforts in a single place.

The current plan is to release 4.2.2 (and future patches to it) out of
ntp-stable, and then add in the current pile of pending changes into
4.2.3 in ntp-dev.

Today, I'm not sure if the next stable release will be 4.2.4 or 4.3.0.

If we do a rewrite of the implementation for the ntp4 protocol and it
happens Soon, this rewrite could be 4.3.0, or if it takes longer (seems
reasonable) it will be 4.4.0 or perhaps 4.5.0.

Dave, do you have any opinion on whether or not we should start fresh?

> But, seeing that we're talking about the exact same version numbers
> as we were in FreeBSD when we did SMPng, I can also say that if
> we do this, Second Systems Syndrome has to be watched at all times.

:)

H


More information about the hackers mailing list