Currently on POSIX systems using poll(2) are supported. To also support Windows a few things are needed:
- Windows doesn't use
int to reference open files (I believe it uses HANDLE of some form). As the handle type leaks into interfaces at a few places it is abstracted away using native_handle_type and it needs to be suitably configured for different systems.
- The library is intended to never require allocations for its own needs. To facilitate that, it is necessary to store data needed by the system's I/O abstraction in an operation state for interfaces like Linux's
io_uring or Window's IOCP. This information is intended to be stored in io_base (as there isn't a binding to io_uring it isn't clear whether it already contains sufficient members to accommodate that). For Windows the io_base would likely include (derive from) an WSAOVERLAPPED structure.
- To hook into the framework a class derived from context_base is needed. It should be possible to implement this using IOCP or using Window's BSD socket-like interface (although that might want to actually go into
poll_context.
There is likely some conditional code needed, e.g., using suitable platform predefined macros.
Currently on POSIX systems using poll(2) are supported. To also support Windows a few things are needed:
intto reference open files (I believe it usesHANDLEof some form). As the handle type leaks into interfaces at a few places it is abstracted away usingnative_handle_typeand it needs to be suitably configured for different systems.io_uringor Window's IOCP. This information is intended to be stored inio_base(as there isn't a binding toio_uringit isn't clear whether it already contains sufficient members to accommodate that). For Windows theio_basewould likely include (derive from) anWSAOVERLAPPEDstructure.poll_context.There is likely some conditional code needed, e.g., using suitable platform predefined macros.