>An additional comment: By definition you are almost never actually
>"done" with a IOBuffer.
>
>They are designed to be input and output buffers for IO.
And now the basic support is there to use them for Stdio.File objects.
Stdio.File now has a new nonblocking mode: Buffered I/O
In this mode the file object maintains two buffers, one for input and
one for output.
The read callback will get the buffer as the second argument, and data
that the user does not read from that buffer is kept until the next
time data arrives from the file (this means you do not have to do your
own buffering of input)
The output buffer is, unsurprisingly, used to output data from.
This has at least three somewhat convenient effects:
o The write callback will now receive that buffer as a second
argument. You just add data to it to write it.
o Adding data to the buffer when /not/ in the write callback will
still trigger sending of data if no write callback is pending.
o Your write callback will not be called until the buffer is actually
empty.
An extremely small demo:
| void null() {}
|
| int main()
| {
| Stdio.IOBuffer output = Stdio.IOBuffer();
| Stdio.File fd = Stdio.File(0);
|
| fd->set_buffer_mode( 0, output );
|
| fd->set_nonblocking( Function.uncurry(output->add), null, null );
|
| return -1;
| }
This will case all data received on stdio to be eched to .. stdin
using buffered output.
Not the most useful application, but it does show how easy it
is. Buffered mode in general is mainly useful because it removes the
need for you to handle the buffers manually in your code.
Currently read() and write() are not in any way modified by having
buffered output enabled, if you interact directly with the file object
it will bypass the buffer. I am unsure if this is a good idea or not.
--
Per
