You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Derek Baum <de...@paremus.com> on 2007/02/08 17:47:40 UTC

apr_procattr_io_set() broken on win32?

Hi,

I've been successfully developing using APR-1.2.7 on Unix for the last 
few months, and now I'm testing on Win/XP.

I'm launching processes like this:
>     apr_procattr_create (&attr, _pool);
>
>     // create pipes to read stdout and stderr
>     apr_procattr_io_set(attr, APR_NO_PIPE, APR_CHILD_BLOCK, 
> APR_CHILD_BLOCK);
>     
>     apr_proc_t proc;
>     stat = apr_proc_create(&proc, argv[0], argv, envv, attr, _pool);
and then reading their output in a non-blocking loop in another thread 
like this:
> for (;;) {
>         apr_size_t nbytes = sizeof(buf);
>         stat = apr_file_read(_proc.out, buf, &nbytes);
>
>         if ((stat != APR_SUCCESS) || (nbytes == 0)) break;
>               _out.append(buf, nbytes);
>         }
> }

This all works fine on Unix, but on Windows, the read blocks, even 
although I call apr_procattr_io_set() to set the parent end of the pipes 
to non-blocking.

The reason for this appears to be a problem in 
apr_create_nt_pipe(file_io/win32/pipe.c), which initialises the 
apr_file_t.timeout fields to -1 (blocking), and does not reset them to 0 
(zero-timeout) if a non-blocking mode has been requested:

Setting these timeouts to zero in my application code, solves the 
problem, although to do this I had to hack into the opaque 
apr_procattr_t structure:
> struct apr_procattr_hack {
>     apr_pool_t *pool;
>     apr_file_t *parent_in;
>     apr_file_t *child_in;
>     apr_file_t *parent_out;
>     apr_file_t *child_out;
>     apr_file_t *parent_err;
>     apr_file_t *child_err;
> };
>
> // add after apr_procattr_io_set() in first code snippet above
> apr_file_pipe_timeout_set(((apr_procattr_hack*)attr)->parent_out, 0);
> apr_file_pipe_timeout_set(((apr_procattr_hack*)attr)->parent_err, 0);

Can you confirm that this is a problem, or am I doing something wrong?
If it is a problem, should I log it as a bug?

Thanks,

Derek


________________________________________________________________________
The information transmitted is intended only for the person(s) or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer. 

Paremus Limited.
107-111 Fleet Street, London EC4A 2AB.  Phone number +44 20 7936 9098
________________________________________________________________________