Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!male!texsun!convex!convex.convex.com!dale From: dale@convex.com (Dale Lancaster) Newsgroups: comp.realtime Subject: Re: Real-time Unix read()s? Message-ID: Date: 20 Nov 90 23:48:50 GMT References: <1990Nov19.161402.7646@Eyring.COM> Sender: usenet@convex.com Lines: 27 In <1990Nov19.161402.7646@Eyring.COM> ron@Eyring.COM (Ron Holt) writes: >In other words, the OS returns a POINTER to the buffer that the OS >(not the user) selected into which the data is put. The idea is that >by letting the OS tell the user where it already has the data, a data >copy can be avoided. I believe there is also a rfree() call to free >this buffer. > How much does this help application performance? Does > anybody have actual performance figures? Unless you go through a buffer cache, most device drivers I have seen or written for Unix uses the process' own buffer to transfer data directly to/from without the intermediate copying to an internal buffer. So providing a rread() seems redundant or unnecessary since how the data is handled is driver dependent and can generally be transferred from user space to device without copying. > What are the drawbacks to using this approach? Its not portable and is redundant to what should be able to be done anyway with a normal read or write. Maybe the vendor had a special need and decided to get around it with a new system call. Using an ioctl is the preferred method for non read/write IO activity system calls. :-) dale