Can we assume SIGQUIT and friends are defined?

[Eric S. Raymond]

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
threaded case.

commit 950f8390012de0b3711430aa180b1d84151b753e
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
    portable mechanism.

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>