f5c6099656
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. |
||
|---|---|---|
| examples | ||
| source/vibe | ||
| tests | ||
| .codecov.yml | ||
| .editorconfig | ||
| .gitignore | ||
| .travis.yml | ||
| appveyor.yml | ||
| CHANGELOG.md | ||
| dub.sdl | ||
| LICENSE.txt | ||
| LICENSE_DE.txt | ||
| README.md | ||
| travis-ci.sh | ||
vibe.d core package
The core package provides the low level I/O and concurrency primitives that are used to implement the higher level systems:
- Event loop management
- Fiber based lightweight tasks, including task local storage and
std.concurrencyintegration - Files, sockets, timers
- Stream type definitions (used for files, sockets and higher level stream types)
- Synchronization primitives (mutexes, condition variables, semaphores, cross task/cross thread events)
- Logging facilities
- Command line argument parsing
- Various smaller utilities
The fundamental building block is the fiber based task concept, together with the event based asynchronous I/O model. This enables developing highly scalable I/O concurrent applications without running into the complexities and design implications that asynchronous I/O programming models usually impose. See the features page for a more detailed explanation.
Supported compilers
The following compilers are tested and supported:
- DMD 2.088.0
- DMD 2.087.1
- DMD 2.086.1
- DMD 2.085.1
- DMD 2.079.0
- LDC 1.17.0
- LDC 1.16.0
- LDC 1.15.0
- LDC 1.14.0
- LDC 1.9.0
Supported up to 1.6.2:
- DMD 2.078.3
- LDC 1.8.0
Supported up to 1.4.7:
- DMD 2.077.1
- DMD 2.076.1
- LDC 1.7.0
- LDC 1.6.0
Supported up to 1.4.3:
- DMD 2.075.1
- DMD 2.074.1
- DMD 2.073.2
- DMD 2.072.2
- LDC 1.5.0
- LDC 1.4.0
- LDC 1.3.0
- LDC 1.2.0
Supported up to 1.3.0:
- DMD 2.071.2
- LDC 1.1.0
Supported up to 1.1.1:
- DMD 2.070.2
- LDC 1.0.0
Separation of the former vibe-d:core package
This is the successor of the vibe-d:core sub package of vibe.d 0.7.x. The API is mostly compatible from a library user point of view, but the whole library has received some heavy lifting under the surface, close to a rewrite. Most classes have been replaced by reference counting structs and @safe nothrow attributes are now used throughout the library, whenever possible. Adding @nogc on the other hand could only be done in a very limited context due to its viral nature and the lack of an @trusted equivalent.
Another major design change is that instead of the previous driver model, there is now a separate, lower-level event loop abstraction (eventcore) which follows a callback based Proactor pattern. The logic to schedule fibers based on events has been pulled out of this abstraction and is now maintained as a single function, leading to a huge improvment in terms of robustness (most issues in the previous implementation have probably never surfaced in practice, but there turned out to be lots of them).
Finally, the stream design has received two big changes. Streams can now either be implemented as classes, as usual, or they can be implemented as structs in a duck typing/DbC fashion. This, coupled with templated wrapper stream types, allows to eliminate the overhead of virtual function calls, enables reference counting instead of GC allocations, and allows the compiler to inline across stream boundaries. The second change to streams is the added support for an IOMode parameter that enables I/O patterns as they are possible when using OS sockets directly. The leastSize and dataAvailableForRead properties will in turn be deprecated.