[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Thread implementations...

    > 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.

    No. As you have to check the 'number of bytes to copy' limit, you
    certainly have to know how much did you already transfer. Anyway, without
    this you cannot have non-blocking copy which breaks traditional UNIX
    semantics of file operations.

    > 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.

    I've never said we should return byte count in case of _error_. Actually,
    I proposed returning errno instead of byte count in such cases.

    > > 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).

    You can save a lot of syscalls by feeding file offsets directy to copy() instead
    of calling up to two lseek()s per copy.

    Have a nice fortnight
    Martin `MJ' Mares <>
    Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
    main(){char *s="main(){char *s=%c%s%c;printf(s,34,s,34);}";printf(s,34,s,34);}

    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.025 / U:13.152 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site