httpd's mod_ext_filter sets up a child process with a stdin of
APR_CHILD_BLOCK, but on windows the parent side of the stdin pipe
defaults to a "non-blocking pipe with an infinite (-1) timeout".  Such
a pipe in unix has its apr_file_pipe_timeout() flipped to 0 during
apr_procattr_io_set().

Net, a subsequent apr_file_read() behaves differently on the two
platforms when no data is available w/o the explicit
apr_file_pipe_timeout_set(foo, 0) call.

While the API might be a little ambiguous, and the caller can
explicitly set the timeout, is this a discrepancy APR should
eliminate?

I don't know if to what extent this intersects (or muddies) the
current windows filehandle work.

-- 
Eric Covener
[EMAIL PROTECTED]

Reply via email to