From rbb@covalent.net Sun Jan 7 00:31:05 2001 Return-Path: Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Delivered-To: mailing list dev@apr.apache.org Received: (qmail 41340 invoked from network); 7 Jan 2001 00:31:05 -0000 Received: from 3ff8faf3.dsl.flashcom.net (HELO koj.covalent.net) (63.248.250.243) by h31.sny.collab.net with SMTP; 7 Jan 2001 00:31:05 -0000 Received: from rbb (helo=localhost) by koj.covalent.net with local-esmtp (Exim 3.16 #1) id 14F3n4-0005XL-00; Sat, 06 Jan 2001 16:34:30 -0800 Date: Sat, 6 Jan 2001 16:34:30 -0800 (PST) From: rbb@covalent.net X-Sender: rbb@koj To: Greg Stein cc: dev@apr.apache.org Subject: Re: cvs commit: apr/network_io/unix sendrecv.c In-Reply-To: <20010106162502.H17220@lyra.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > We don't actually use os_cork or os_uncork on FreeBSD, so we shouldn't > > define them. This removes some warnings. > >... > > --- sendrecv.c 2001/01/04 22:02:34 1.55 > > +++ sendrecv.c 2001/01/07 00:00:07 1.56 > > @@ -198,7 +198,7 @@ > > * need to move these to the top... > > */ > > > > -#if APR_HAVE_CORKABLE_TCP > > +#if APR_HAVE_CORKABLE_TCP && !defined(__FreeBSD__) > > > > /* TCP_CORK & TCP_NOPUSH keep us from sending partial frames when we > > * shouldn't. They are however, mutually exclusive with TCP_NODELAY > > I don't understand this. Why don't we just /not/ define > APR_HAVE_CORKABLE_TCP on the FreeBSD boxes? (in the ./configure script) That > seems more appropriate than adding platform-specific checks into the code. Both methods do the same thing. I decided to put the checks in the code, because I am assuming that at some point we will actually add support for os_cork and os_uncork to the code. I wanted the special code to disable os_cork and os_uncork as close to the code that would use it as possible. I figured whoever adds support for os_cork and os_uncork will actually need to look at those functions, so they will see e !defined(__FreeBSD__), whereas if the special check was made in the configure script, that could go un-noticed when the changes were made, thus making it harder for the developer who does the work. I really don't care which we choose, but the warnings were bugging me, and I wanted them to go away. :-) Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------