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
