Am 08.11.2017 um 17:32 schrieb Dietmar Maurer:
But the module does not use any threads, and use blocking IO calls.
So all vibe.d file-io is in fact blocking? What do I miss?The old Posix implementation indeed just used blocking calls (except for the win32 driver). However, it will be deprecated very soon, and the replacement, vibe-core, already uses actual thread-backed I/O for non-Windows systems through the "eventcore" library: https://github.com/vibe-d/eventcore/blob/master/source/eventcore/drivers/threadedfile.d
I do not really get why you use threads. Why don't you simply use libevent2 for that (that is the whole purpose of having libevent2)?
Eventcore doesn't use libevent*, but directly talks to the operating
system APIs. But as far as I know, libevent also uses a thread pool for
file I/O. Until recently, there has been no way to implement
asynchronous file operations without threads on Linux. There is the aio
API in glibc, but even that uses threads internally.
However, there is libaio, which wraps the actual kernel mode
asynchronous I/O support available on all modern Linux kernels, and this
is what will likely be targeted in the future. Until then, and for other
operating systems for which no explicit asynchronous file I/O support
has been implemented, the generic multi-threaded approach provides a
pretty decent fallback.
- The reason being to get more control over performance characteristics
of the abstraction layer, and to avoid the external library dependency,
which is a frequent issue for new users or different operating systems
with differing libevent versions or none at all.
Unfortunately libaio-dev also needs to be explicitly installed, so based
on the latter argument it may be added as an opt-in feature, keeping
thread based file I/O as the default.