The processing of system level events is basic need of most of applications. When multiple events should be processed in single thread some mechanism to allows select which events should be wait for and how they should be processed is required.
Many of projects are assembled from multiple libraries/components. These libraries should be portable and need to be able to integrate into different environments and applications. It is possible to write many of them without need to block on events such way, that they are only fed by data by main application and provide data back. But there are many situations, when even libraries depend processing system level events and need to register into application wide events processing mechanism.
But there is critical problem for libraries that they have to follow application environment selected event processing mechanism or introduce own one and force application use it. Problem is to combine libraries written for different environments or to select different application environment the library has been designed for.
The goal of uLevPoll is to provide common interface which allows to hide environment differences and allows to write libraries which can be used in diferent environments without need of rewrite or recompile.
To achieve goal next list of requirements has been defined
use such FD monitoring mechanism, which would be well portable
even binary version of compiled libraries has to be independent of application selected main loop mechanism used by applications which use components/libraries → libraries have to adapt for main loop used by applications
libraries should allow to be used with minimal set of external dependencies to allow their use in small embedded applications
but components should integrate well even with graphical or large applications, so defined interface should not prevent use of Gtk or Qt for main loop in applications
the used mechanism should allow to switch to high throughput solution (as libevent is for example) when required in future.
The uLevPoll library API/ABI is defined on above basis. It exposes minimal amount of information directly to user - only "handler" like event trigger structure with minimal set of fields and pointer to one field of event base structure with information about used operations set.