The callback must *always* be called at some point, because the generic async->sync logic in vibe-core otherwise has no way to know whether to expect a callback or not.
- Fixes an assertion triggered by accessing a file field in releaseRef
- Fixed a potential leak of file system watcher handles when calling releaseRef from inside the supplied callback - this was the reason why the fixed assertion error wasn't triggered by the test code
Removes overlapped I/O events when a handle gets closed prematurely (before all events have been processed) to avoid potential range violation errors as a consequence.
Unfortunately the built-in assert GC allocates an exception, which means that if called directly or indirectly form a finalizer, the assertion will not become visible and instead an InvalidMemoryOperationError is thrown.
This implements a custom nogc_assert() function that directly prints the assertion message and uses abort() to end the process.
Calling WinSock functions from inside of a completion routine results in undefined behavior, because the completion routine may be triggered within another WinSock function that enters an alertable wait state. For this reason, none of the callbacks that are triggered by overlapped I/O may be invoked directly from a completion routine.
To solve this, a ConsumableQueue is filled with all completion events that occur and is processed after each MsgWaitForMultipleObjectsEx call.
Under certain (rare) circumstances, the receive buffer contains data from a file instead of the expected FILE_NOTIFY_INFORMATION structure. No signs of handle or buffer reuse could be found, so the cause for this remains unclear. Until the cause can be narrowed down, this keeps the issue visible while avoiding to crash the application.
Explicitly gets the read/write slot from the handle map from within the callback instead of dereferencing the pointer assigned when starting the operation. This makes sure that no dangling reference is accessed. Instead, if the slot got reused before the callback is invoked (which is a bug), an assertion will be triggered if the slot now has a different handle type.
The underlying file handle and the associated slot could previously be destroyed before the I/O callback had been finally called. Now the callback itself is responsible to destroying the handle.
