anchor.diff:  used to, such as `read(fd, &val, 4)`.
   
   Now to be fair, Martin Sustrik had the best intentions when he created the
  -state machine model around which nanomsg is built.  I do think that from
  -experience this is one of the most dense and unapproachable parts of nanomsg,
  +state machine model around which _nanomsg_ is built.  I do think that from
  +experience this is one of the most dense and unapproachable parts of _nanomsg_,
   in spite of the fact that Martin's goal was precisely the opposite.  I
   consider this a "failed experiment" -- but hey failed experiments are the
   basis of all great science.
   
  -
  -Thread Challenges
  ------------------
  -
  -While nanomsg is mostly internally single threaded, I decided to try to
  -emulate the simple architecture of mangos using system threads.  (mangos
  -has the benefit of goroutines.)  Having been well and truly spoiled by
  -Solaris/illumos threading (and especially Solaris/illumos kernel threads),
  -I thought this would be a reasonable architecture.
  +=== Thread Challenges
  +
  +While _nanomsg_ is mostly internally single threaded, I decided to try to
  +emulate the simple architecture of _mangos_ using system threads.  (_mangos_
  +benefits greatly from _Go_'s excellent coroutine facility.)  Having been well
  +and truly spoiled by _illumos_ threading (and especially _illumos_ kernel
  +threads), I thought this would be a reasonable architecture.
   
   Sadly, this initial effort, while it worked, scaled incredibly poorly --
  -even so-called "modern" operating systems like macOS 10.12 and Windows 8.1
  +even so-called "modern" operating systems like _macOS_ 10.12 and _Windows_ 8.1
   simply melted or failed entirely when creating any non-trivial number of
   threads.  (To me, creating 100 threads should be a no-brainer, especially if
   one limits the stack size appropriately.  I'm used to be able to create
  
positive.code:       for nanomsg vs. ZeroMQ.
  
  
  Background
  ----------
  
  I became involved in the nanomsg community back in 2014, when
  I wrote https://github.com/go-mangos/mangos[mangos] as a pure Golang
  implementation of the wire protocols behind nanomsg.  I did that work
  because I was dissatisfied with ZeroMQ's licensing and C++ baggage, and
  I needed something that would work with Golang on Solaris, which at the time
  lacked support for cgo (so I could not just use an FFI binding.)  This gave
  me a lot of detail about the internals of nanomsg and the SP protocols.
  At the time, it was the only alternate implementation those protocols.
  
  It would not be wrong to say that one of the goals of mangos was to teach
  me about golang.  It was my first non-trivial golang project.
  
  While working with mangos, I wound up implementing a number of additional
  features, such as a TLS transport, the ability to bind to wild card ports,
  and the ability to determine more information about the sender of a message.
  This was incredibly useful in a number of projects.
  
  I initially looked at nanomsg itself, as I wanted to add a TLS transport
  to it, and I needed to make some bug fixes (for protocol bugs for example),
  and so forth.
  
  
  State Machine Madness
  ---------------------
  
  What I ran into was a challenging mess of state machines.
  nanomsg has dozens of state machines, many of which feed into others,
  such that tracking flow through the state machines is incredibly painful.
  
  Worse, these state machines are designed to be run from a single worker
  thread.  This means that a given socket is entirely single theaded; you
  
negative.code: from one process to another you may have to execute up to 6 extra system
  calls, beyond the 2 required to actually send and receive the message.
  
  NOTE: Its even more hideous to support this on Windows, where there is no
        `pipe(2)` system call, so we have to cobble up a loopback TCP connection
        just for this event notification, in addition to the system call
        explosion.
  
  There are cases where this file descriptor logic is easier for existing
  applications to integrate into event loops (e.g. they already have a thread
  blocked in `poll()`.)
  
  But for many cases this is not necessary.  A simple callback mechanism
  would be far better, with the FDs available only as an option for code
  that needs them.  This is the approach that we have taken with _nng_.
  
  As another consequence of our approach, we do not require file descriptors
  for sockets at all, so it is possible to create applications containing
  _many_ thousands of `inproc` sockets with no files open at all.  (Obviously
  if you're going to perform real I/O to other processes or other systems,
  you're going to need to have the underlying transport file descriptors
  open, but then the only real limit should be the number of files that you
  can open on your system.  And the number of active connections you can maintain
  should ideally approach that system limit closely.)
  
  === POSIX APIs
  
  Another of Martin's goals, which seems worthwhile at first, was the
  attempt to provide a familiar POSIX API (based upon the BSD socket API).
  As a C programmer coming from UNIX systems, this really attracted me.
  
  The problem is that the POSIX APIs are actually really horrible.  In
  particular the semantics around `cmsg` are about as arcane and painful as
  one can imagine.  Largely, this has meant that extensions to the `cmsg
  API simply have not occurred in _nanomsg_.
  
  The `cmsg` API specified by POSIX is as bad as it is because POSIX had
  requirements not to break APIs that already existed, and they needed to
  shim something that would work with existing implementations, including
  getting across a system call boundary. _nanomsg_ has never had such
  constraints.
  
  Oh, and there was that whole "design by committee" aspect.
  
  Attempting to retain low numbered "socket descriptors" had its own
  problems -- a huge source of use-after-close bugs, which made the
  use of `nn_close()` incredibly dangerous for multithreaded sockets.
  (If one thread closes and opens a new socket, other threads still using
  the old socket might wind up accessing the "new" socket without realizing
  it.)
  
  The other thing is that BSD socket APIs are super familiar to UNIX C
  programmers -- but experience with _nanomsg_ has taught us already that these
  are actually in the minority of _nanomsg_'s users.  Most of our users are
  coming to us from {cpp} (object oriented), _Java_, and _Python_ backgrounds.
  For them the BSD sockets API is frankly somewhat bizarre and alien.
  
  With _nng_, we realized that constraining ourselves to the mistakes of the
  POSIX API was hurting rather than helping. So _nng_ provides a much friendlier
  interface for getting properties associated with messages.
  
  In _nng_ we also generally try hard to avoid reusing
  an identifier until no other option exists.  This generally means most
  applications won't see socket reuse until billions of other sockets
  have been opened.  There is little chance for accidental reuse.
  
  
  == Compatibility
  
  Of course, there are a number of existing _nanomsg_ consumers "in the wild"
  already.  It is important to continue to support them.  So I decided from
  the get go to implement a "compatibility" layer, that provides the same
  API, and as much as possible the same ABI, as legacy _nanomsg_.  However,
  new features and capabilities would not necessarily be exposed to the
  the legacy API.
  
  Today _nng_ offers this.  You can relink an existing _nanomsg_ binary against
  _libnng_ instead of _libnn_, and it usually Just Works(TM).  Source
  compatibility is almost as easy, although the application code needs to be
  modified to use different header files.
  
  NOTE: I am considering changing the include file in the future so that
  it matches exactly the _nanomsg_ include path, so that only a compiler
  flag change would be needed.
  
  == Asynchronous IO
  
  As a consequence of our experience with threads being so unscalable,
  we decided to create a new underlying abstraction modeled largely on
  Windows IO completion ports.  (As bad as so many of the Windows APIs
  are, the IO completion port stuff is actually pretty nice.)  Under the
  hood in _nng_ all I/O is asynchronous, and we have `nni_aio` objects
  for each pending I/O.  These have an associated completion routine.
  
  The completion routines are _usually_ run on a separate worker thread
  