www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: os-windows/5671: CGI print to stdout while reading POST from stdin deadlocks Win32 Pipes
Date Mon, 31 Jan 2000 22:10:00 GMT
The following reply was made to PR os-windows/5671; it has been noted by GNATS.

From: "William A. Rowe, Jr." <wrowe@lnd.com>
To: <submit@bugz.apache.org>, <apache-bugdb@apache.org>
Cc:  
Subject: RE: os-windows/5671: CGI print to stdout while reading POST from stdin deadlocks
Win32 Pipes
Date: Mon, 31 Jan 2000 16:03:37 -0600

 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ++
 
 Followup - UNIX behavior;
 
 After compiling the (revised) sample code with libm.a under Linux/Apache
 1.3.6
 I have the same result, although the deadlock threshold seems much larger
 (perhaps about 64K each of POSTed and reply data before locking up).
 
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ++
 
 Followup - Possible NT Workarounds
 
 1) Status: Tested - Result: Functional
 
    Expanded the allocators in lines 2414, 2417 and 2425 of src/main/alloc.c
    The fourth arg to the Win32 CreatePipe call is the requested buffer size.
    Minimally, this should be HUGE_STRING_LEN.  A return buffer of 0x10000 is
    not a bad idea either.  This simply stretches the pipe, and is subject to
    the same deadlock situation, although with more breathing room.
 
 2) Status: Untested - Result: Hypothetical
 
    Create a TRUE temp file as the input or output queue.  The input queue
    makes the most sense, since this could be conditionally created based on
    the size of the POSTed query, and left in pipe mode for smaller requests.
    The disadvantage is wasting space for the temp file given file upload
    scripts with small result transmissions.  The output queue suffers the
    opposite fate, and in any case we cannot predict the result size.
 
 3) Status: Untested - Result: Hypothetical
 
    Under NT only (and not across 95/98) the anon. pipes are really named
    pipes assigned unique names.  Therefore, the SetNamedPipeHandleState
    API call will modify an NT or Win/2000 pipe state.  While depreciated
    by MS, setting the PIPE_NOWAIT flag on simply one handle may eliminate
    the deadlock.  There would be several approaches...
 
    Set hPipeInputWrite to PIPE_NOWAIT, therefore failing in Apache
    upon buffer overflow.
 
    Set hPipeOutputWrite to PIPE_NOWAIT prior to sending the POSTed data,
    then switching it back to PIPE_WAIT prior to reading the results.  This
    approach has MANY weaknesses, esp. since we have lost our handle to
    hPipeOutputWrite (and don't really want to hang on to it, for reasons
    documented in the source code and in the MS API), and that it changes
    the expected behavior on the poor client process.
 
    I leave it to others to come up with more ideas on this line.
 
 4) Status: Untested - Target Platform: Apache 2.0
 
    Using a peek into the stdout result and reading the result back to the
    client after each write to the stdin stream could cure the deadlock.
    This would also offer an async behavior scripters are expecting.  Risk -
    if Apache reads a partial stream header/result code string we have
    problems!
 
    Obviously parallel Read and Write threads would solve this issue, if
    the client can be served the results while still transmitting the POSTed
    query.  WARNING: The read from stdout thread cannot begin until the
    client is up and running, or a race condition may result!
 
 Thoughts?
 

Mime
View raw message