Input wanted: move `queueRead` and `queueWrite` to `AbstractIoUringChannel`?

[bbeaupain]

Looking for some input on this one!

When initially designing the project, I decided to place the main I/O methods in the IoUring class like so:

• ring.queueRead(channel, buffer)
• ring.queueWrite(channel, buffer)

Where a channel could be backed by either a socket or a file. This felt like it more closely matched what's happening under the hood in the native layer, where all reading/writing is queued, and only executes when the ring executes.

Recently, @ohpauleez made a contribution that allows for reading/writing files with offsets in the destination file - including a third parameter to the above methods, called offset. This is a great addition, but the call will explode if made with a channel that is backed by a socket instead of a file.

Proposing moving the I/O queuing methods to the specific channel implementation, instead of the ring:

• channel.queueRead(ring, buffer) // also possibly "offset" for File-specific channel implementations
• channel.queueWrite(ring, buffer)

This requires an API change, but removes a potential foot-gun for usage situations. I think this is a worthwhile change, but open to other input or suggestions.

[mattrpav]

Yes, having the ability to do read and write offsets would enable using nio_uring for files used as data stores.

Also, while there are is overlap in read/write operations, the fact that the IoRing class has to cast up to a socket to handle different events feels like an inversion class extension design.

Operations for files have to sift through condition statements for ACCEPT and CONNECT that never occur.