Dasynq manual
This is the manual for the Dasynq event loop library (version 1.1.6).- Introduction
- Reference
Introduction
An event loop library provides a means for waiting on events that occur asynchronously. One good example is network input/output; in a server with multiple client connections, a mechanism is needed to wait until data is available, or until it is possible to write data, to one or more of the current connections (and to be able to identify which connections are ready). Dasynq is a multi-platform, thread-safe C++ library which provides such functionality.
Note that an event loop generally supports managing various different kinds of event. Dasynq can be used for detecting:
- read/write readiness on sockets, pipes, and certain devices including terminals and serial lines;
- connections to listening sockets;
- reception of POSIX signals (such as SIGTERM); and
- child process status notifications (termination etc).
Dasynq is fully thread safe, allowing events to be polled and processed on any thread. There are some limitations on the use the Dasynq API in a multi-threaded application. However, when used in a single-thread application, the API is just about as straight-forward as the API of most other event loop libraries.
Dasynq is also intended to allow development of extremely robust client applications. Where possible, it allows pre-allocation of resources to prevent allocation failures from occurring at inopportune moments during program execution.
Caveat
The Itanium C++ ABI, which is the basis for the ABI on many platforms (for instance it is the ABI which the Sys V ABI for x86-64 defers to), has one very unfortunate design flaw: throwing an exception requires making a heap allocation (and if the allocation fails, the process terminates). Implementations have an "emergency allocation pool" for exceptions which should mean that the allocation fails only in truly exceptional circumstances, but the possibility is there. Unfortunately Dasynq at this stage sometimes uses exceptions (in some cases handling them internally rather than exposing them to the user of the API) and in theory could trigger process termination on these platforms. I consider this a bug in the ABI and in the platforms implementing it, however a future version of Dasynq may endeavour to avoid use of exceptions entirely (or at least make it possible for the client to avoid unwittingly triggering exceptions).