Date: Wed, 28 May 2003 15:23:14 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Marc Slemko <marcs@znep.com>, Igor Sysoev <is@rambler-co.ru> Cc: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal Message-ID: <p05210604bafabafcdf79@[128.113.24.47]> In-Reply-To: <Pine.NEB.4.53.0305281125460.28029@rhombus.znep.com> References: <Pine.BSF.4.21.0305282219570.51226-100000@is> <Pine.NEB.4.53.0305281125460.28029@rhombus.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:35 AM -0700 5/28/03, Marc Slemko wrote: >On Wed, 28 May 2003, Igor Sysoev wrote: > > > 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. > >As people have said a few times now, making an API change to work >around a bug in the implementation of sendfile() simply doesn't >make any sense, especially when there are other workarounds you >can use until it is fixed that impose a very low overhead. No >one is saying it can't be solved without fixing sendfile(), we >are just saying it _shouldn't_ be because any API changes will >be around for a very long time. For what it's worth, the debate so far has not convinced me that there would be enough benefit from this API change to bother with it. If you (Igor) wanted to write up the code and some good benchmarks to prove a significant performance boost, that would probably help many of us who are just watching the debate go by. So far I've just seen that you really really want it, while some pretty reasonable arguments have been made against making an API change for this. At the moment, I would side with the people saying "do not make the API change", particularly if it's just to hide a bug in sendfile(). -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05210604bafabafcdf79>