Open bbeaupain opened 1 month ago
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.
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.