From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 5 Dec 2009 08:24:45 -1000 From: Tim Newsham To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Message-ID: References: <20091205031747.GA8759@nipl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [9fans] ideas for helpful system io functions Topicbox-Message-UUID: a8b90fb0-ead5-11e9-9d60-3106f5b1d025 >> 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