Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 May 2003 08:45:02 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Igor Sysoev <is@rambler-co.ru>
Cc:        arch@freebsd.org
Subject:   Re: sendfile(2) SF_NOPUSH flag proposal
Message-ID:  <3ED62AFE.187A40F9@mindspring.com>
References:  <Pine.BSF.4.21.0305291139090.52120-100000@is>

next in thread | previous in thread | raw e-mail | index | archive | help
Igor Sysoev wrote:
> On Wed, 28 May 2003, Terry Lambert wrote:
> > Igor Sysoev wrote:
> > > The portability argument is bogus because sendfile() portability is nonsense.
> >
> > Darwin has sendfile.  See the released source code: it matches
> > the FreeBSD semantics, from what I can tell.
> 
> So now FreeBSD/Darwin is second pair after AIX/MVS that has the same sendfile()
> prototype.  It surely improves the sendfile() portability.  Undoubtedly.

FreeBSD, NetBSD, OpenBSD, Darwin.


> > > 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 no workaround for the latency issue, which comes from
> > the fact that a trap handles the request for more pages, and
> > that blocks all callers.  Threads has the same problem in libc_r.
> 
> The workaround idea is simple - a preloading.  But implementation on user
> level is complex.  In FreeBSD 4.x I see three ways:
> 
> *) the use of aio_read() to read the single bytes;

This does not fix the problem.  See the extensive discussion,
last month, about the differences between libthr and libc_r
and libpthreads.  Even when doing async I/O, you stall all
threads in any model that isn't 1:1 when you fault for a
user page in a system call.

This is because a fault on a user page results in entering
the trap handler, which suspends the calling program until
such time as the fault is satisfied, or a SIGSEGV is raised
to the caller because the fault cannot be satisfied.


> *) the use rfork()ed helper processes to read the single bytes;
> *) and the use the pool of rfork()ed processes to handle connections.

We call this "libthr".


> But all of them requires significant changes of an application.

Yes, it does.


> > > Five people ?
> >
> > Bill Fenner, Matt Dillon, Peter Jeremy, Marc Slemko, Terry Lambert,
> > Garance Droshin.
> 
> At time of your mail there were only 4 people, in order of appearance:
> Peter Jeremy, you, Matt Dillon, and Marc Slemko. Bill Fenner's email
> was sent one and a half hour after yours and just before my response.
> Garance Droshin's mail was sent several hours later.

Apparently, I received some mail that did not go to the list.

However, if you are willing to include the contents of the
"sendfile() broken" thread, I could add three more before
your time deadline, including Bruce Evans.

But more to the point, so far you are the only one who is not
saying that sendfile() needs to be fixed, instead of kludged.

-- Terry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ED62AFE.187A40F9>