On Wed, Nov 10, 2021 at 3:21 PM <yla...@apache.org> wrote:
> --- apr/apr/trunk/poll/unix/wakeup.c (original)
> +++ apr/apr/trunk/poll/unix/wakeup.c Wed Nov 10 14:20:57 2021
> @@ -36,6 +36,9 @@ apr_status_t apr_poll_create_wakeup_pipe
> pool)) != APR_SUCCESS)
> return rv;
>
> + /* Read end of the pipe is non-blocking */
> + apr_file_pipe_timeout_set(wakeup_pipe[0], 0);
I'm not really sure about this Windows specific change actually.
On Windows the read/write ends of the pipe are SOCKET handles cast to
HANDLE, and while Readfile() seems to be documented to accept SOCKET
handles, PeekNamedPipe() isn't.
Now by setting the timeout to zero, PeekNamedPipe() might be called in:
- apr_poll_drain_wakeup_pipe()
- apr_file_read()
- read_with_timeout()
- if timeout == 0 && !PeekNamedPipe()
return EAGAIN
- Readfile()
Since I don't have a Windows machine at hand, anyone willing to test
or chime in on this heresy?
Otherwise I'll revert because I have no way to test it, but I think
that apr_poll_drain_wakeup_pipe() might block on Windows for the same
reason as r1894914 for platforms with poll()able pipes.
Regards;
Yann.
