The following reply was made to PR general/885; it has been noted by GNATS.
From: Illuminatus Primus <[EMAIL PROTECTED]> To: Dean Gaudet <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: general/885: After a period of time (not found to coincide with server rehashes or any specific access), the server will read requests, but return no data (and close the connection). It will still respond to a server-status request though. Date: Fri, 14 Nov 1997 02:06:39 -0500 (EST) On Thu, 13 Nov 1997, Dean Gaudet wrote: > Oh I think you misunderstand how ap_slack works ... it never returns -1 > ... it returns the original fd when it can't remap it above the slack > line.... so what you were seeing was correct. At least I can't reproduce > any problem under linux 2.0.30 or 2.1.29. > > (Notwithstanding the interesting code in the kernel ... but I know what > it's up to at least.) > > Dean Yes, I realize that ap_slack tries to return the original fd if a new one cannot be allocated, but unforunately if there are lots of fds open and fcntl fails to remap the fd on a 2.0.29 kernel, it will return a closed fd :).. maybe i misworded the sentence about open() returning -1 once in a while.. But in any case: what's going on with the code in the kernel? It's possible that the fcntl fd remapping code has never changed; in the tests I never got to see if the behavior was different since the fds seem to run out while doing open() in 2.1.53 even if there would appear to be some spares below the slack line. Maybe it's a bug, or maybe there is a new strange way of limiting per-process fds.. Well, good luck :) [EMAIL PROTECTED]
