Can we assume SIGQUIT and friends are defined?
Eric S. Raymond
esr at thyrsus.com
Tue Sep 13 03:47:48 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
> What's the story with HAVE_IO_COMPLETION_PORT? Do we know what that is for?
Yes, though I could't have told you that yesterday.
An IO completion part is a place where a process doing asynchronous I/O can
look to see which such requests have completed, rather analogous to looking
at file descriptor sets retrned by a select(2) call in the synchronous or
Author: Eric S. Raymond <esr at thyrsus.com>
Date: Mon Sep 12 13:17:55 2016 -0400
Remove HAVE_IO_COMPLETION_PORT code.
In theory this general approach might have worked on. e.g.,
Solaris 10 and AIX. In practice the handler code was Windows
only, and there are good reasons not to do it this way.
First, it's not clear asynchronous I/O is any win at all under modern
conditions. The disadvantage is that it's a complexity and defect
attractor; the advantage is reducing average latency and jitter due to
processing time in a synchronous I/O loop. In past times, with slower
processors, this was a serious issue.
But in 2016 we know from field experience that synchronous I/O produces
good NTP performance on Unix systems that don't do asynchronous
I/O. Thus, it can be dropped.
If the standards for "good performance" rise to the point where we
want asynchronous I/O again, the right way to do it will not with
an OS-specific extension but with POSIX threads or some other
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel