just to be able to read user packets from TAP
split the UDP and TUN listeners into separate event queues
added some notes in tuntap-windows (mostly gutting it since we do a lot of the stuff ourselves)
need to be able to queue up a TUN read/write at each tick
then finish dealing with it in the main event loop
which is damn near impossible to do along with unix-style asio
that waits for data to appear/disappear before signalling
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.
up next: debugging the windows client code
stretch goal: prototype hosting a full masternode on Windows Server (still _highly_ experimental when it _does_ appear)
add win32 tun glue, fix llarp timebase
(In fact, _both_ of these are guaranteed to exist on their respective platforms.)
also, tuntap is now wired up to the windows port
old hard-coded inline asm is still included if requested.
-rick
nb: is a vector of eight floats not the same layout as a simple linear array of same? (Aside from the alignment requirements)
netbsd-family build fixes, also - the AVX2 codepaths are _compiler-specific_, they use features _exclusive_ to gcc and clang