From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8ccc8ba40912050344od31827by29522b75a51892c6@mail.gmail.com> References: <45bb8a0916edcb2ee86883ebeea8945e@brasstown.quanstro.net> <20091205081032.GJ8759@nipl.net> <8ccc8ba40912050344od31827by29522b75a51892c6@mail.gmail.com> Date: Sat, 5 Dec 2009 08:32:30 -0800 Message-ID: <13426df10912050832l3b1674a3sbd5e15f5ba040315@mail.gmail.com> From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] ideas for helpful system io functions Topicbox-Message-UUID: a8803ad2-ead5-11e9-9d60-3106f5b1d025 On Sat, Dec 5, 2009 at 3:44 AM, Francisco J Ballesteros wrote: > If you insist on 'unreading', you could just put a front-end process that > keeps per-request data so that your external process can ask the > front-end for all the data again. The easiest way to implement unread is not to read in the first place. If you're only reading small amounts of data, say less then 1024 bytes, and then forking a process to handle the rest, then by all means don't use IO that reads in lots of data you may not want. Instead: read(fd, &c, 1); and then there's no "overread" to deal with. That said, you can prototype unread() so why not? unread(fd, data, size); Attach the "unread" data to the open file struct, modify read so that if it sees this data it reads it first, try it out. Why not? Plan 9 is there to be hacked on, so hack it. Sam, the rule is, just do it. This hackability is one thing that makes Plan 9 so attractive. ron