Hi,
This code as is works well for me with TAP-Windows both for sending and receiving frames. All there is left to do is add documentation. Can I expect this will be merged?

Is there anything similar that can be done on Linux? Some kind of uv_custom_t?

@bzoz On Linux there is uv_poll_t which allows detecting when an arbitrary file descriptor is readable or writable, which is enough to integrate many types of I/O including TUN/TAP device. uv_poll_t exists on Windows too but is for sockets only not overlapped operations.

So, can maybe uv_poll_t be extended? I've took a quick look at uv_poll_s it looks like it could be used to hold everything that uv_overlapped_t needs, even without breaking v1.x ABI.

Right, this can be merged into uv_poll_t, for example:

• New init function uv_poll_init_overlapped (alongside existing uv_poll_init and uv_poll_init_socket).
• Existing function uv_poll_start is the equivalent of current uv_overlapped_start.
• Functions to get OVERLAPPED* and IOCP HANDLE are added: uv_poll_get_overlapped, uv_poll_get_iocp.
• uv_poll_stop must not be called for uv_poll_t handles of overlapped kind (it cannot be implemented in any reasonable way due to IOCP design).

Can the persons with authority please comment on these proposals? Can I expect this feature to be merged? If so, should it be a new handle type as in the current pull request or should it be added to uv_poll_t?

May be related to #484. We've been wanting something like this for node-serialport for a long time.

@joshperry One should certainly be able to implement serial top on top of uv_overlapped_t. I am using this code for the TAP-Win32 driver and it works without issues. The application code is here: https://github.com/ambrop72/aipstack/tree/master/examples/tap_windows

Anyway I think that the architecture of libuv is a bit off in that different handle types are not easily composeable and reused internally. Ideally the core event loop implementation would only provide and know about the primitive event facilities, which are timers and whatever is the native IO notification mechanism on the platform (file descriptor readiness or IOCP). Everything else could be build on top of that (e.g. uv_loop_t shouldn't need to know about tcp, udp, filesystem, etc).

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.