A co_usb context referencing event handler service.
This type acts as a handle to a service without exposing the service itself to the user.
- The problem
The reason for this type to exist is the fact that libusb_context can accept initialization options, the user can and will want to assign an event handler and the process of initializing a service turns into a long boilerplate. The context aims to smooth out this interaction by providing a thin wrapper interface for initializing the service.
- The intrusivity and the lifetimes
The context type is by design only a handle to a service, not in any way intrusive. An alternative approach could see the context itself become a place for the event handler, libusb_context and stop source to reside in. However, this would mean that the lifetime of this data would be decoupled from the executor, and a slightly wrong code regarding context lifetime would see the invalid memory access to a destroyed object occur. To prevent this scenario, the data HAS to live in a service storage directly bound to an executor lifetime.
- Limitations
Creating multiple contexts for a single executor is well-defined to be wrong. It will reinitialize the context and rebind and restart the event handler, spawning multiple different event handlers or services is unsupported within a single executor on a level of Capy. Creating multiple single-threaded event handlers is unsupported by libusb and will break. If the goal was to implement a multi-threaded event handling - provide a custom implementation of co_usb::ev::detail::EventHandler that properly manages the locking of libusb events.
1.9.8