[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


Richard Jones Tel: +44 171 598 7557 Fax: 460 4461
Orchestream Ltd. 125 Old Brompton Rd. London SW7 3RP PGP:
"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

 \ /
  Last update: 2005-03-22 13:43    [W:0.160 / U:3.044 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site