Messages in this thread | | | Date | Thu, 25 Jun 1998 16:30:55 +0000 | From | Richard Jones <> | Subject | Re: Thread implementations... |
| |
Martin Mares wrote: > > > This is almost copy (see my earlier posting). Unfortunately I > > thought long and hard about this last night, and copy does > > seem to be extremely subtle, particularly for error handling. > > > > eg. what do you do if the read fails with an error? > > what do you do if the read fails with EWOULDBLOCK? > > what do you do if the write fails with an error? - put back the data? > > what do you do if the write fails with EWOULDBLOCK? - check for > > this *before* doing the read? > > Just return a status word containing INPUT_WOULDBLOCK, OUTPUT_WOULDBLOCK, > INPUT_ERROR and OUTPUT_ERROR flags and passing a pointer where to store > number of bytes copied or errno.
Well, it's possible, but somewhat ugly. The real objection I can see is that if you're optimizing this by, say, doing DMA directly between the devices you may not actually have the data to hand back to the caller or indeed know very much about how much data you actually wrote out.
This is consistent with write(2), though. As I understand it[*], if write returns an error, then under some circumstances you are not guaranteed that none of the data was written. Possibly the case, for example, for files where you run out of disk space, or NFS where the server hit a Big Red Switch Error half way through ...
So the fact that copy sometimes behaves unpredictable in the presence of write errors ain't too much of a problem.
> > Update to my previous posting. I think the prototype should be: > > > > ssize_t copy (int from_fd, int to_fd, size_t *nbytes); > > > > so the kernel can return the number of bytes actually > > copied in the event of an error. I'll try and implement > > this some time and see if it's workable. > > It would be better to allow selecting offsets in both source and destination > files.
What's wrong with lseek? Perhaps you misunderstand -- copy is just a replacement for a loop with read + write -- so it works from the current file position (if, indeed, the fds refer to files at all).
Rich.
[*] My understanding may be at odds with reality :-)
-- Richard Jones rjones@orchestream.com Tel: +44 171 598 7557 Fax: 460 4461 Orchestream Ltd. 125 Old Brompton Rd. London SW7 3RP PGP: www.four11.com "boredom ... one of the most overrated emotions ... the sky is made of bubbles ..." Original message content Copyright © 1998
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |