You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@locus.apache.org on 2000/04/07 00:23:54 UTC
cvs commit: apache-2.0/src/lib/apr/lib Makefile.in apr_slack.c
rbb 00/04/06 15:23:51
Modified: src/lib/apr/lib Makefile.in
Removed: src/lib/apr/lib apr_slack.c
Log:
Remove the slack stuff from APR. This isn't actually used anywhere in
Apache 2.0 anymore.
PR: 13
Submitted by: William A. Rowe Jr <wr...@lnd.com>
Reviewed by: Ryan Bloom
Revision Changes Path
1.11 +0 -5 apache-2.0/src/lib/apr/lib/Makefile.in
Index: Makefile.in
===================================================================
RCS file: /home/cvs/apache-2.0/src/lib/apr/lib/Makefile.in,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Makefile.in 2000/03/18 12:32:17 1.10
+++ Makefile.in 2000/04/06 22:23:50 1.11
@@ -22,7 +22,6 @@
apr_md5.o \
apr_pools.o \
apr_signal.o \
- apr_slack.o \
apr_snprintf.o \
apr_tables.o \
apr_getpass.o
@@ -86,10 +85,6 @@
apr_signal.o: apr_signal.c $(INCDIR)/apr_config.h \
$(INCDIR)/apr_lib.h $(INCDIR)/apr_general.h $(INCDIR)/apr.h \
$(INCDIR)/apr_errno.h $(INCDIR)/apr_file_io.h $(INCDIR)/apr_time.h \
- $(INCDIR)/apr_thread_proc.h
-apr_slack.o: apr_slack.c $(INCDIR)/apr_config.h $(INCDIR)/apr_lib.h \
- $(INCDIR)/apr_general.h $(INCDIR)/apr.h $(INCDIR)/apr_errno.h \
- $(INCDIR)/apr_file_io.h $(INCDIR)/apr_time.h \
$(INCDIR)/apr_thread_proc.h
apr_snprintf.o: apr_snprintf.c $(INCDIR)/apr_config.h \
$(INCDIR)/apr_lib.h $(INCDIR)/apr_general.h $(INCDIR)/apr.h \
Re: cvs commit: apache-2.0/src/lib/apr/lib Makefile.in apr_slack.c
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@apache.org wrote:
>
> On Fri, 7 Apr 2000, Rodent of Unusual Size wrote:
>
> > rbb@locus.apache.org wrote:
> > >
> > > Remove the slack stuff from APR. This isn't actually used
> > > anywhere in Apache 2.0 anymore.
> >
> > Are we back to only including things in APR that the HTTP server
> > needs? I thought APR was supposed to provide portability; if
> > the HTTP server needed this in 1.3, is it safe to assume that
> > no-one else will ever want/need it?
>
> I actually asked about the slack stuff a while ago, and Dean's response
> was that it wasn't needed. Here is a basica run-down of his reasons (from
> what I remember) I actually looked thisup in the archives yesterday, but
> it took a while to find the correct month. :-)
>
> 1) One of the major reasons for the slack stuff was the 256 FILE limit on
> some SVR4 platforms. With the removal of the Buffered I/O from APR, this
> need goes away.
Except it probably shouldn't.
> 2) With threads, the rest of the reasons for slack go away too, because
> processes need to just play well.
Err, not all platforms have threads.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
RE: cvs commit: apache-2.0/src/lib/apr/lib Makefile.in apr_slack.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: rbb@shell.ntrnet.net [mailto:rbb@shell.ntrnet.net]On Behalf Of
> rbb@apache.org
>
> On Fri, 7 Apr 2000, Rodent of Unusual Size wrote:
>
> > rbb@locus.apache.org wrote:
> > >
> > > Remove the slack stuff from APR. This isn't actually used
> > > anywhere in Apache 2.0 anymore.
> >
> > Are we back to only including things in APR that the HTTP server
> > needs? I thought APR was supposed to provide portability; if
> > the HTTP server needed this in 1.3, is it safe to assume that
> > no-one else will ever want/need it?
>
> I actually asked about the slack stuff a while ago, and
> Dean's response
> was that it wasn't needed. Here is a basica run-down of his
> reasons (from
> what I remember) I actually looked thisup in the archives
> yesterday, but
> it took a while to find the correct month. :-)
I will add an even better argument to this. The then-current
ap_slack was not terribly portable, and had an ugly #ifdef APACHE
code path that was clearly not useful in other derivative works.
I would support slack if it were well implemented for other
projects, exactly what my forthcoming ap_hooks proposal will
look like. Not tied with Apache, and portable across apps.
Bill
Re: cvs commit: apache-2.0/src/lib/apr/lib Makefile.in apr_slack.c
Posted by rb...@apache.org.
On Fri, 7 Apr 2000, Rodent of Unusual Size wrote:
> rbb@locus.apache.org wrote:
> >
> > Remove the slack stuff from APR. This isn't actually used
> > anywhere in Apache 2.0 anymore.
>
> Are we back to only including things in APR that the HTTP server
> needs? I thought APR was supposed to provide portability; if
> the HTTP server needed this in 1.3, is it safe to assume that
> no-one else will ever want/need it?
I actually asked about the slack stuff a while ago, and Dean's response
was that it wasn't needed. Here is a basica run-down of his reasons (from
what I remember) I actually looked thisup in the archives yesterday, but
it took a while to find the correct month. :-)
1) One of the major reasons for the slack stuff was the 256 FILE limit on
some SVR4 platforms. With the removal of the Buffered I/O from APR, this
need goes away.
2) With threads, the rest of the reasons for slack go away too, because
processes need to just play well.
Take a look at Dean's message in the November archive:
<Pi...@twinlark.arctic.org>
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/lib/apr/lib Makefile.in apr_slack.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@locus.apache.org wrote:
>
> Remove the slack stuff from APR. This isn't actually used
> anywhere in Apache 2.0 anymore.
Are we back to only including things in APR that the HTTP server
needs? I thought APR was supposed to provide portability; if
the HTTP server needed this in 1.3, is it safe to assume that
no-one else will ever want/need it?
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>