[src/trunk]: src/external/mit/libuv Add build glue

[christos <christos%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/236a5bd33ce0
branches:  trunk
changeset: 1010391:236a5bd33ce0
user:      christos <christos%NetBSD.org@localhost>
date:      Sun May 24 19:28:10 2020 +0000

description:
Add build glue

diffstat:

 external/mit/libuv/Makefile     |      5 +
 external/mit/libuv/lib/Makefile |     66 +
 external/mit/libuv/lib/libuv.3  |  10855 ++++++++++++++++++++++++++++++++++++++
 external/mit/libuv/mkpc         |     27 +
 external/mit/libuv/pkgconfig.mk |     12 +
 5 files changed, 10965 insertions(+), 0 deletions(-)

diffs (truncated from 10985 to 300 lines):

diff -r 244876af995e -r 236a5bd33ce0 external/mit/libuv/Makefile
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/external/mit/libuv/Makefile       Sun May 24 19:28:10 2020 +0000
@@ -0,0 +1,5 @@
+#      $NetBSD: Makefile,v 1.1 2020/05/24 19:28:10 christos Exp $
+
+SUBDIR+=       lib
+
+.include <bsd.subdir.mk>
diff -r 244876af995e -r 236a5bd33ce0 external/mit/libuv/lib/Makefile
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/external/mit/libuv/lib/Makefile   Sun May 24 19:28:10 2020 +0000
@@ -0,0 +1,66 @@
+# $NetBSD: Makefile,v 1.1 2020/05/24 19:28:10 christos Exp $
+
+.include <bsd.own.mk>
+
+MKLINT=        no
+LIB=   uv
+
+INCS=  uv.h uv/unix.h uv/bsd.h uv/errno.h uv/version.h uv/threadpool.h
+INCSDIR=/usr/include
+MAN=   libuv.3
+
+LIBUVDIR=${.CURDIR}/../dist
+
+.PATH: ${LIBUVDIR}/src ${LIBUVDIR}/src/unix ${LIBUVDIR}/include
+SRCS+= \
+async.c \
+atomic-ops.h \
+core.c \
+dl.c \
+fs.c \
+getaddrinfo.c \
+getnameinfo.c \
+internal.h \
+loop-watcher.c \
+loop.c \
+pipe.c \
+poll.c \
+process.c \
+random-devurandom.c \
+signal.c \
+stream.c \
+tcp.c \
+thread.c \
+tty.c \
+udp.c
+
+SRCS+= \
+bsd-ifaddrs.c \
+bsd-proctitle.c \
+kqueue.c \
+netbsd.c \
+posix-hrtime.c
+
+SRCS+= \
+fs-poll.c \
+idna.c \
+inet.c \
+random.c \
+strscpy.c \
+threadpool.c \
+timer.c \
+uv-data-getter-setters.c \
+uv-common.c \
+version.c
+
+CPPFLAGS+=     -I${LIBUVDIR}/include -I${LIBUVDIR}/src
+
+LIBDPLIBS+=    kvm ${NETBSDSRCDIR}/lib/libkvm
+
+SHLIB_MAJOR=   1
+SHLIB_MINOR=   0
+
+PKGCONFIG=libuv
+.include "${.CURDIR}/../pkgconfig.mk"
+
+.include <bsd.lib.mk>
diff -r 244876af995e -r 236a5bd33ce0 external/mit/libuv/lib/libuv.3
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/external/mit/libuv/lib/libuv.3    Sun May 24 19:28:10 2020 +0000
@@ -0,0 +1,10855 @@
+.\" Man page generated from reStructuredText.
+.
+.TH "LIBUV" "3" "May 24, 2020" "1.38.0" "libuv API documentation"
+.SH NAME
+libuv \- libuv documentation
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.SH OVERVIEW
+.sp
+libuv is a multi\-platform support library with a focus on asynchronous I/O. It
+was primarily developed for use by \fI\%Node.js\fP, but it\(aqs also used by \fI\%Luvit\fP,
+\fI\%Julia\fP, \fI\%pyuv\fP, and \fI\%others\fP\&.
+.sp
+\fBNOTE:\fP
+.INDENT 0.0
+.INDENT 3.5
+In case you find errors in this documentation you can help by sending
+\fI\%pull requests\fP!
+.UNINDENT
+.UNINDENT
+.SH FEATURES
+.INDENT 0.0
+.IP \(bu 2
+Full\-featured event loop backed by epoll, kqueue, IOCP, event ports.
+.IP \(bu 2
+Asynchronous TCP and UDP sockets
+.IP \(bu 2
+Asynchronous DNS resolution
+.IP \(bu 2
+Asynchronous file and file system operations
+.IP \(bu 2
+File system events
+.IP \(bu 2
+ANSI escape code controlled TTY
+.IP \(bu 2
+IPC with socket sharing, using Unix domain sockets or named pipes (Windows)
+.IP \(bu 2
+Child processes
+.IP \(bu 2
+Thread pool
+.IP \(bu 2
+Signal handling
+.IP \(bu 2
+High resolution clock
+.IP \(bu 2
+Threading and synchronization primitives
+.UNINDENT
+.SH DOCUMENTATION
+.SS Design overview
+.sp
+libuv is cross\-platform support library which was originally written for \fI\%Node.js\fP\&. It\(aqs designed
+around the event\-driven asynchronous I/O model.
+.sp
+The library provides much more than a simple abstraction over different I/O polling mechanisms:
+\(aqhandles\(aq and \(aqstreams\(aq provide a high level abstraction for sockets and other entities;
+cross\-platform file I/O and threading functionality is also provided, amongst other things.
+.sp
+Here is a diagram illustrating the different parts that compose libuv and what subsystem they
+relate to:
+[image]
+.SS Handles and requests
+.sp
+libuv provides users with 2 abstractions to work with, in combination with the event loop:
+handles and requests.
+.sp
+Handles represent long\-lived objects capable of performing certain operations while active. Some examples:
+.INDENT 0.0
+.IP \(bu 2
+A prepare handle gets its callback called once every loop iteration when active.
+.IP \(bu 2
+A TCP server handle that gets its connection callback called every time there is a new connection.
+.UNINDENT
+.sp
+Requests represent (typically) short\-lived operations. These operations can be performed over a
+handle: write requests are used to write data on a handle; or standalone: getaddrinfo requests
+don\(aqt need a handle they run directly on the loop.
+.SS The I/O loop
+.sp
+The I/O (or event) loop is the central part of libuv. It establishes the content for all I/O
+operations, and it\(aqs meant to be tied to a single thread. One can run multiple event loops
+as long as each runs in a different thread. The libuv event loop (or any other API involving
+the loop or handles, for that matter) \fBis not thread\-safe\fP except where stated otherwise.
+.sp
+The event loop follows the rather usual single threaded asynchronous I/O approach: all (network)
+I/O is performed on non\-blocking sockets which are polled using the best mechanism available
+on the given platform: epoll on Linux, kqueue on OSX and other BSDs, event ports on SunOS and IOCP
+on Windows. As part of a loop iteration the loop will block waiting for I/O activity on sockets
+which have been added to the poller and callbacks will be fired indicating socket conditions
+(readable, writable hangup) so handles can read, write or perform the desired I/O operation.
+.sp
+In order to better understand how the event loop operates, the following diagram illustrates all
+stages of a loop iteration:
+[image]
+.INDENT 0.0
+.IP 1. 4
+The loop concept of \(aqnow\(aq is updated. The event loop caches the current time at the start of
+the event loop tick in order to reduce the number of time\-related system calls.
+.IP 2. 4
+If the loop is \fIalive\fP  an iteration is started, otherwise the loop will exit immediately. So,
+when is a loop considered to be \fIalive\fP? If a loop has active and ref\(aqd handles, active
+requests or closing handles it\(aqs considered to be \fIalive\fP\&.
+.IP 3. 4
+Due timers are run. All active timers scheduled for a time before the loop\(aqs concept of \fInow\fP
+get their callbacks called.
+.IP 4. 4
+Pending callbacks are called. All I/O callbacks are called right after polling for I/O, for the
+most part. There are cases, however, in which calling such a callback is deferred for the next
+loop iteration. If the previous iteration deferred any I/O callback it will be run at this point.
+.IP 5. 4
+Idle handle callbacks are called. Despite the unfortunate name, idle handles are run on every
+loop iteration, if they are active.
+.IP 6. 4
+Prepare handle callbacks are called. Prepare handles get their callbacks called right before
+the loop will block for I/O.
+.IP 7. 4
+Poll timeout is calculated. Before blocking for I/O the loop calculates for how long it should
+block. These are the rules when calculating the timeout:
+.INDENT 4.0
+.INDENT 3.5
+.INDENT 0.0
+.IP \(bu 2
+If the loop was run with the \fBUV_RUN_NOWAIT\fP flag, the timeout is 0.
+.IP \(bu 2
+If the loop is going to be stopped (\fBuv_stop()\fP was called), the timeout is 0.
+.IP \(bu 2
+If there are no active handles or requests, the timeout is 0.
+.IP \(bu 2
+If there are any idle handles active, the timeout is 0.
+.IP \(bu 2
+If there are any handles pending to be closed, the timeout is 0.
+.IP \(bu 2
+If none of the above cases matches, the timeout of the closest timer is taken, or
+if there are no active timers, infinity.
+.UNINDENT
+.UNINDENT
+.UNINDENT
+.IP 8. 4
+The loop blocks for I/O. At this point the loop will block for I/O for the duration calculated
+in the previous step. All I/O related handles that were monitoring a given file descriptor
+for a read or write operation get their callbacks called at this point.
+.IP 9. 4
+Check handle callbacks are called. Check handles get their callbacks called right after the
+loop has blocked for I/O. Check handles are essentially the counterpart of prepare handles.
+.IP 10. 4
+Close callbacks are called. If a handle was closed by calling \fBuv_close()\fP it will
+get the close callback called.
+.IP 11. 4
+Special case in case the loop was run with \fBUV_RUN_ONCE\fP, as it implies forward progress.
+It\(aqs possible that no I/O callbacks were fired after blocking for I/O, but some time has passed
+so there might be timers which are due, those timers get their callbacks called.
+.IP 12. 4
+Iteration ends. If the loop was run with \fBUV_RUN_NOWAIT\fP or \fBUV_RUN_ONCE\fP modes the
+iteration ends and \fBuv_run()\fP will return. If the loop was run with \fBUV_RUN_DEFAULT\fP
+it will continue from the start if it\(aqs still \fIalive\fP, otherwise it will also end.
+.UNINDENT
+.sp
+\fBIMPORTANT:\fP
+.INDENT 0.0
+.INDENT 3.5
+libuv uses a thread pool to make asynchronous file I/O operations possible, but
+network I/O is \fBalways\fP performed in a single thread, each loop\(aqs thread.
+.UNINDENT
+.UNINDENT
+.sp
+\fBNOTE:\fP
+.INDENT 0.0
+.INDENT 3.5
+While the polling mechanism is different, libuv makes the execution model consistent
+across Unix systems and Windows.
+.UNINDENT
+.UNINDENT
+.SS File I/O
+.sp
+Unlike network I/O, there are no platform\-specific file I/O primitives libuv could rely on,
+so the current approach is to run blocking file I/O operations in a thread pool.
+.sp
+For a thorough explanation of the cross\-platform file I/O landscape, checkout
+\fI\%this post\fP\&.
+.sp
+libuv currently uses a global thread pool on which all loops can queue work. 3 types of
+operations are currently run on this pool:
+.INDENT 0.0
+.INDENT 3.5
+.INDENT 0.0
+.IP \(bu 2
+File system operations
+.IP \(bu 2
+DNS functions (getaddrinfo and getnameinfo)
+.IP \(bu 2
+User specified code via \fBuv_queue_work()\fP
+.UNINDENT
+.UNINDENT