Quoting from the commit message for your convenience:

> The option argument identifies the file descriptor number of a UNIX
> listening socket which was inherited from the parent process when said
> parent exec'd mandoc.
>
> mandoc will accept one connection at a time on that socket. As long as
> the connection lives, mandoc reads 1-byte messages with ancillary data
> (control information) from the connection. The ancillary data is used to
> pass three file descriptors from the parent process to mandoc. These
> file descriptors are then dup2'ed to fd 0, fd 1 and fd 2, respectively.
>
> After the file descriptors have been set up, a single manpage is read
> from stdin and processed to stdout/stderr.
>
> This change effectively adds a batch processing mode to mandoc, which
> eliminates the fork+exec overhead that otherwise accompanies the
> conversion of a large number of manpages. The resulting speed-up has
> been observed to exceed a factor of 6, reducing the total conversion
> wall-clock time of about a 470k manpages from more than 2 hours to
> a mere 22 minutes.

To expand on the rationale: quicker conversion…

1. allows us to provide our users more recent manpages (we can run
more frequently)
2. hogs fewer resources which can instead be used for actually serving manpages
3. massively simplifies our disaster recovery story: we can just
re-generate the entire repository within a small number of hours,
instead of facing days of downtime

As per http://man.openbsd.org/OpenBSD-current/man3/CMSG_DATA.3,
control information has been around since 4.2BSD, so support across
operating systems should be good.

No file system objects are required, no data format needs to be
defined and no additional library dependencies are added.

I have attached a minimal example implementation (demo.c) so that you
can convince yourself this approach works.

Please let me know what you think. Thanks!

-- 
Best regards,
Michael