the native async event system on windows
is _not_ very good at getting external events
(i.e. we receive data, but we don't get any indication
that this ever happened)
find some place in the C code to place the worker thread procedure
until such time that michael presents the new thread pool class
fix unix
get a new event port each time and delet in the event loop after use
msys2 grabs its reactos sdk headers straight out of git
most cross-compilers use the versioned releases (v6 as of last week)
huh. for once setting the windows version macros doesn't break anything.
use the base class impl for llarp::tcp_conn::sendto
can't seem to escape quotes ;-;
yeah this need to stay out of the unix build
turn on gnu extensions
apple stuff
remove duplicate code
clean up
fix vtable
clang-format
parameter checks
(with its now-obsolete distinction between socketfd and fd)
sockets and file descriptors used to be distinct objects....back in the
16-bit Winsock 1.1 era, which needlessly complicated the 32-bit port
back then. these days one can use [Read|Write]File(2) to operate on
sockfds...which also have some of the semantics of [read|write]v(2)
i.e. the scatter-gather thing it's known for is done in async handler
-rick
variants are nice
added note to self
clang-format
link abyss properly
oops
shut up
*shrugs*
oops forgot to start winsock
moved our async io status flags to the base class
let derived classes override them as needed
this is probably a synchronous op _anyway_
fix typo
wtf
- sockets are a distinct (non-negative) file descriptor
- plain old file descriptors are opaque handles
this makes the specialisations of llarp::ev_io on win32 type-safe as
- TAP-Windows v9 adapter is a plain old device file (same as on UNIX and Linux)
- UDP listeners are sockets, so the type must change (from signed to unsigned int) to accomodate Winsock2
