- Directly uses OS facilities instead of Phobos to avoid string processing overhead and to enable fast skipping of non-directories
- Introduces a DirectoryListMode, similar to SpanMode
- Uses low-overhead channels to reduce the communication overhead between the calling thread and the worker thread that calls the OS
- Adds FileInfo.path to properly support the new recursive directory iteration schemes
Adds a low-overhead mode to Channel!T that causes the buffer to be fully processed before notifying waiting peers instead of notifying immediately once data/space is available. This heavily reduces the overhead of cross-task/thread notifications at the expense of introducing processing latency and requiring a call to close() to guarantee that all data has been processed.
Makes sure that `FindClose` gets called before `listDirectory` returns to avoid a race-condition, where a successive modification of the directory fails with "access denied".
Calling Task.interrupt() on a task that is already finished, but ran on the same fiber would trigger an assertion failure instead of returning silently.
IOMode.once causes the read() to return with IOStatus.wouldBlock immediately, which previously resulted in erroneously reporting WaitForDataStatus.noModeData instead of timeout.
See vibe-d/vibe.d#2483
The file I/O versions of cancelRead and cancelWrite in eventcore currently do not reliably cancel the operation in a synchronous fashion, leading to continued buffer accesses after the cancellation call. In case of the Windows version, this also means that the OVERLAPPED structure can be illegally reused for the next operation, while the previous one hasn't been canceled, yet.
A solution to this issue may require a fundamental change in the file I/O API of eventcore, and the optimal design of that still needs to be worked out. For this reason, we simply avoid using the cancellation functions in vibe-core for now to avoid memory corruption issues. This does mean that interrupting a task that does file I/O won't work anymore.
