Re: sendfile(2) SF_NOPUSH flag proposal

From: Igor Sysoev (is_at_rambler-co.ru)
Date: 05/28/03

  • Next message: Marc Slemko: "Re: sendfile(2) SF_NOPUSH flag proposal" 
    Date: Wed, 28 May 2003 22:21:00 +0400 (MSD)
To: Terry Lambert <tlambert2@mindspring.com>

    On Wed, 28 May 2003, Terry Lambert wrote:

    > Igor Sysoev wrote:
    > > On Wed, 28 May 2003, Terry Lambert wrote:

    > > > Why are you so dead-set on adding crufty flags, when three
    > > > people who have been in that code before (I back-ported the
    > > > external mbuf code and sendfile to FreeBSD 4.2 and 4.3 at
    > > > one point; Matt has lived in that code; Peter had his nose
    > > > in for quite a while; etc.) say that it's broken, and the
    > > > correct thing to do is to fix it, not add a bunch of kludge
    > > > code to work around the bugs that shouldn't be there in the
    > > > first place?
    > >
    > > Well, how do your code handle the partially filled file packets ?
    >
    > Here we get to the nub of things, then. You are being
    > obstinate not because you really want the flags, but
    > because you want someone else to do the actual work of
    > fixing sendfile for you.

    No, I do want these flags because they resolve the problem of partially
    filled packets. I believe that this problem can be solved without a fixing
    the sendfile() implementation. The real argument was Peter Jeremy's one
    that overhead of flags vs. overhead of setsockopt() is negligible after all.
    The portability argument is bogus because sendfile() portability is nonsense.

    The drawback that really annoyed me is that sendfile() blocks on a reading
    from a disk while a sending to non-blocking socket. Although I see three
    workarounds it's much better to fix this inside sendfile().

    > There's probably no reason to continue this conversation,
    > unless you are going to insist on it. Five people have
    > told you the correct approach is to fix sendfile(2), and
    > you have ignored all of us. Three people, not all the same
    > people as before, have told you that if you could measure a
    > statistically significant performance improvement from your
    > proposed changes, we wouldn't object to your code going in,
    > even though it breaks source compatability further.

    Five people ? I probably missed something - there were only four people
    except me that discussed this subject.

    > Other than writing the correct code for you, there's little
    > else we can do, and I, at least, have other code I need to
    > write, to solve my own problems.

    Well, Terry, write your code and I will write my own.

    Igor Sysoev
    http://sysoev.ru/en/

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Marc Slemko: "Re: sendfile(2) SF_NOPUSH flag proposal"

    Relevant Pages

    • Re: sendfile(2) SF_NOPUSH flag proposal
      ... On Wed, 28 May 2003, Terry Lambert wrote: ... > the FreeBSD semantics, ... So now FreeBSD/Darwin is second pair after AIX/MVS that has the same sendfile() ... The workaround idea is simple - a preloading. ...
      (freebsd-arch)
    • Re: sendfile(2) SF_NOPUSH flag proposal
      ... On Mon, 26 May 2003, Terry Lambert wrote: ... I know some other drawbacks but I do not see now the ways to resolve them. ... It allows to save two syscalls on each sendfile() call ... FreeBSD 4.x has no zero_copyso mmaped files would be copied. ...
      (freebsd-arch)