From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <4B00F115-FC3F-4D31-9725-2187B121F19B@lsub.org> From: Francisco J Ballesteros To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 7 Dec 2009 15:41:31 +0100 Subject: Re: [9fans] ideas for helpful system io functions Topicbox-Message-UUID: aa166164-ead5-11e9-9d60-3106f5b1d025 I think he wants copyfile + a kproc. On 07/12/2009, at 15:37, rogpeppe@gmail.com wrote: > 2009/12/7 Sam Watkins : >> I meant for example if a process is reading from its stdin a open >> file 'A' and >> writing to stdout the input of a pipe 'B', rather than looping and >> forwarding >> data it may simply "join" these two fds, and exit. The OS will >> then do what is >> necessary to make sure the data can travel from A to B (and/or vice >> versa) with >> the minimum effort needed. > > i'm not sure how you think this would work. > > a file descriptor is essentially a passive object - it responds > to read, write, etc requests on it, but it doesn't do anything > of its own accord. > > if i do: > > fd1 := open("/foo1", ORDWR); > fd2 := open("/foo2", ORDWR); > fd3 := fdjoin(fd1, fd2); > > what is going to happen? > something has got to initiate the requests to actually > shift the data, and it's not clear which direction the > data will flow. > > this is an optimisation, right? what parts of the current system > could be speeded up by the use of this primitive? > > [/mail/box/nemo/msgs/200912/452]