Messages in this thread | | | Date | Thu, 25 Jun 1998 12:39:58 +0000 | From | Richard Jones <> | Subject | Re: Thread implementations... |
| |
David Luyer wrote: > > Erik Corry wrote: > > How about... > * ftp server sending out static objects > * proxy cache serving requests > * imap/pop with maildir mailbox format sending mail items > * news server sending out articles to peers and clients > * sendmail sending mail from queue
> sendfile(fd-in, fd-out, options); > > fd-in - file descriptor to disk file (? is this needed as a restriction) > fd-out - file descriptor to any object > options - eg, close on send completion, sync/async. etc.
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?
It could get pretty ugly. See Larry's splice paper too.
Of course one could say that for 99% of applications that would actually benefit from the copy syscall, those apps just stop doing the transfer, close both FDs and log an error when any of the error conditions occur, so perhaps we just stipulate this in the implementation - ie. `things will be fine with copy(2), provided there are no errors any time ...'.
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.
Rich.
-- 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
| |