ap_slack, do we need it?

[Ryan Bloom <rb...@raleigh.ibm.com>]

I have been looking through some APR functions, and I noticed ap_slack.
We never seem to call ap_slack anywhere in the code.  Am I missing
something, or can we remove this function?  I can't find why we needed it
in the first place, so I'm probably missing something.

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

Re: ap_slack, do we need it?

[Dean Gaudet <dg...@arctic.org>]

it's not needed per se... the motivations for using it are essentially
platform brokenness and select brokenness.

the first is that solaris (and i think other sysvr4 derivatives?) has a
stupid 256 fd limit for FILE *.  so putting whatever we can above the 255
mark gives us more room to work within that limit on solaris.

another reason is that lower numbered fds require less cpu overhead in
select...

another reason is that some libraries (i.e. the resolver) have embedded
FD_SETSIZE limits which are lower than what apache uses.  so if we try to
leave space down low in the fd set, then those libraries won't run into
trouble.

there may be other reasons i'm forgetting.

so we leave the < 16 gap for that purpose -- for use within each request
(to keep fds low for the select), and to give 3rd party libraries a break.

now you can guess that none of this is terribly helpful in threaded
applications... the libraries just plain have to work, because one app can
easily have hundreds of descriptors open.

so, you could say that we should stop giving those platforms a free ride
and get rid of the slack.  you've at least dealt with FILE * already.

Dean

On Mon, 22 Nov 1999, Ryan Bloom wrote:

> 
> I have been looking through some APR functions, and I noticed ap_slack.
> We never seem to call ap_slack anywhere in the code.  Am I missing
> something, or can we remove this function?  I can't find why we needed it
> in the first place, so I'm probably missing something.
> 
> Ryan
> 
> _______________________________________________________________________
> Ryan Bloom		rbb@raleigh.ibm.com
> 4205 S Miami Blvd	
> RTP, NC 27709		It's a beautiful sight to see good dancers 
> 			doing simple steps.  It's a painful sight to
> 			see beginners doing complicated patterns.	
> 
>