Re: [9fans] ideas for helpful system io functions

[Tim Newsham <newsham@lava.net>]

>> I can see two possible solutions for this, both of which would be useful in
>> my
>> opinion:
>>
>>  - an "unread" function, like ungetc, which allows a program to put back
>> some
>>    data that was already read to the OS stdin buffer (not the stdio
>> buffer).
>>    This might be problematic if there is a limit to the size of the
>> buffers.
>
> Wouldn't it be a lot easier to change the convention of the
> program you're forking and execing to take 1) a buffer of data
> (passed via cmd line, or fd, or whatever) and 2) the fd with
> the unconsumed part of the data?  The only data that would have
> to be copied would be the preconsumed data that you would have
> wanted to "unget".

ps. if you wanted to hide this ugliness of passing a buffer and
fd to a child process instead of just passing an fd, you could
still solve it in userland without a syscall.  Write a library
that does buffered IO.  Include unget() if you like.  Write the
library in a way that you can initialize it after a fork/exec
to pick up state from the parent (ie. by taking two fds,
reading the buffer from the first, and continuing on with the
2nd when it is exhausted).

Is there much benefit in doing this in the kernel instead?

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com