Oh, nothing really. I just always wanted to open a door to a room where

APACHE 2.0 STATUS:						-*-text-*-

Last modified at [$Date: 2001/06/26 11:59:50 $]

Last modified at [$Date: 2001/06/27 21:14:15 $]

Release:

    WARNING: ALWAYS check srclib/apr/STATUS and srclib/apr-util/STATUS

    * File handle caching in mod_file_cache is broken in the multi

      threaded MPMs. The original intent of caching file handles 

      was that these handles would ONLY be used in an apr_sendfile()

      call.  With recent optimizations added to core_output_filter

      to pipeline output byte streams, we actually read bytes from

      these cached file handles into buffers. The problem is that

      while it is okay for multiple threads to share a file handle

      for use on a sendfile call (because the filepointer is not used, 

      in sendfile) it is NOT okay for threads to share a file handle

      for reads or writes (because the filepointer is used in reads

      and writes).  This may also be broken on a few quirky platforms

      whose sendfile() actually uses the file pointer.  Jeff was looking

      into that.

      Potential Solutions:

      1. We either need to ensure that a cached file handle is only

         used on a sendfile call (Bill prefers this solution. I think.).

      2. Cliff Woolley has some ideas about a custom bucket type

         that would recognise when an apr_file_t is cached (thus shared

         across threads) and do the right thing to ensure that the

         filepointer does not get trashed.  The idea here is that the

         "cacheable" file bucket would never allow its file handle to be

         read by any method OTHER than sendfile.  Attempts to do otherwise

         would result in the file being re-opened for sync io into the

         request pool, and the new file handle would get put into a regular

         file bucket which would then be read.  This method thus incorporates

         the spirit of solution #1 while having a fall-back protection

         scheme.  Note that mod_file_cache can still attempt to

         be discriminatory and DECLINE requests that it believes will

         result in an apr_bucket_read() call; this solution just allows

         it to not worry TOO much about missing some cases.  Note that

         no locking is involved, and in the worst case (ie, when the cached

         file bucket is read) we are no worse off performance-wise than

         if we'd just DECLINED in the first place.  Patch forthcoming.

      3. You can share a file handle across threads in Windows if you

         open the file for OVERLAPPED io. A file opened for overlapped

         io does not have a file pointer; each thread must manage

         tracking its location in the file explicity. This is a cool

         feature IMHO.  APR would need to be expanded to handle 

         reading and writing to files opened for overlapped io 

         (specifically to manage a per-thread file pointer and handle

         async io events internal to APR). This doesn't fix the problem

         under *ix though. 

    * There is a bug in how we sort some hooks, at least the pre-config

      hook.  The first time we call the hooks, they are in the correct 

      order, but the second time, we don't sort them correctly.  Currently,

      more generic to support other encryption libraries.

    * Performance & Debug: Eliminate most (and perhaps all) of the 

      malloc/calloc/frees in the bucket brigade code.  Need some 

      malloc/free calls in the bucket brigade code.  Need some 

      light weight memory management functions that allow freeing 

      memory (putting it back into a memory pool) when it is no 

      longer needed. Enabling simple debugging features like guard

      bands, double free detection, etc. would be cool but certainly

      not a hard requirement.

        Status: Cliff, David, et al have discussed using the blocks SMS

	        for this.  First step is to s/malloc/apr_sms_malloc/g, etc.

		We could then have a thread-private SMS that is pointed

		to by the conn_rec's or something so that all calls to

		the bucket create functions can pass in that SMS.  No locks

		required.  Should be fast... 

    * Eliminate unnecessary creation of pipes in mod_cgid