While it does make sense to make readers unblock by setting the read
event on teardown, this is something that consumers of the library
should do _before_ calling EndSession, not something that makes sense
for the library to do itself. The reason is that, in the hypothetical
case in which this makes sense, immediately after unblocking the reader
via SetEvent, the function goes on to free all of the memory that that
reader might want to use. So, rather, the proper shutdown flow is from
the application side, and looks like:
Closing = true;
SetEvent(WintunGetReadWaitEvent());
WaitForReadersToReturn();
WintunEndSession();
Alternatively, rather than using WaitForSingleObject on the read event,
consumers can WaitForMultipleObjects and include a shutdown event, which
is what the example code does.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Log runtime information to quickly check whether the values are sane
when analyzing error logs sent in by users.
Signed-off-by: Simon Rozman <simon@rozman.si>
This makes the API parallel:
Wintun*Allocate*SendPacket -> WintunSendPacket
WintunReceivePacket -> Wintun*Release*ReceivePacket
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
- Return pointer to ring buffer with packet data allowing clients to
read/write directly. This eliminates one memcpy().
- Make sending/receiving packets thread-safe.
Signed-off-by: Simon Rozman <simon@rozman.si>
We must not use the process heap, as it is changeable. Client may change
it causing our HeapFree() to use wrong heap.
Signed-off-by: Simon Rozman <simon@rozman.si>
Rather than every client reinvent the art of using the Wintun and its
ring buffers, we offer helper structs and functions to unify and
simplify Wintun usage.
Signed-off-by: Simon Rozman <simon@rozman.si>
