20432, "jeremiah-corrado", "Should IO Buffering be configurable as a parameter on Channel?", "2022-08-11T20:21:09Z"
The QIO_CH_ALWAYS_UNBUFFERED IO hint indicates that a channel should not use buffering. This is currently used in some of the shootout benchmarks.
In some discussion on this thread, it was noted that the ioHintSet type should not be used to pass this directive to the runtime because it affects which methods are available on the channel interface (specifically: mark, revert, and commit do not work without buffering).
Option 1 :
The channel type could toggle buffering behavior with a boolean param which mediates method availability via where clauses (similar to the way locking is currently used on the channel type).
For example, the mark method might look like this:
And presumably the File methods that return a channel would also take a boolean param as an argument. It would likely have a default value of true, as buffering is desirable in the vast majority of situations.
Option 2:
Non-buffering IO could also be supported by an entirely separate non-buffering-channel type (the unsupported methods would of course not be available on this interface)
The File methods that return a channel, would still have a boolean argument to toggle between buffering and non-buffering IO, except in this case, the return type would depend on the value of that argument.