On Fri, Nov 19, 2021 at 12:44 PM Mladen Turk wrote:
>
> On 18/11/2021 11:14, Yann Ylavic wrote:
> >
> > Does it work for you?
> >
>
> Please apply the patch to trunk.
> It works, but I'll add few bits so it matches the 1.7x branch
> API (eg, file_socket_pipe_close vs apr_file_socket_pipe_close in
On 18/11/2021 11:14, Yann Ylavic wrote:
On Wed, Nov 17, 2021 at 8:10 PM Mladen Turk wrote:
This new patch does not blindly set nonblocking for the pipe-socket
(like r1894917) but adds a new ->socket boolean to Windows' struct
apr_file_t (similar to the existing ->pipe flag), such that
On 18/11/2021 11:14, Yann Ylavic wrote:
On Wed, Nov 17, 2021 at 8:10 PM Mladen Turk wrote:
If only a single thread can call apr_poll_drain_wakeup_pipe
it shoud be OK.
Calling apr_poll{set,cb}_poll() concurrently on the same pollset is
quite undefined behaviour with our implementation(s), so
On Wed, Nov 17, 2021 at 8:10 PM Mladen Turk wrote:
>
> If only a single thread can call apr_poll_drain_wakeup_pipe
> it shoud be OK.
Calling apr_poll{set,cb}_poll() concurrently on the same pollset is
quite undefined behaviour with our implementation(s), so I think we
are OK here.
> However I'd
On 17/11/2021 18:50, Yann Ylavic wrote:
On Wed, Nov 17, 2021 at 5:19 PM Mladen Turk wrote:
On 17/11/2021 16:53, Yann Ylavic wrote:
apr_poll_drain_wakeup_pipe() should consume each byte sent on the pipe
corresponding to a wakeup_set flip.
Yes, its basically just one byte and one call
On Wed, Nov 17, 2021 at 5:19 PM Mladen Turk wrote:
>
> On 17/11/2021 16:53, Yann Ylavic wrote:
>
> > apr_poll_drain_wakeup_pipe() should consume each byte sent on the pipe
> > corresponding to a wakeup_set flip.
> >
>
> Yes, its basically just one byte and one call to the apr_file_getc.
> The
On Wed, Nov 17, 2021 at 2:28 PM Mladen Turk wrote:
>
> Attached a patch that fixes those huge writes to drain pipe
Thanks, looks good to me.
I've also reverted r1894914 because the new synchronization with
atomics requires that we always block when reading the pipe now.
Attached a patch that fixes those huge writes to drain pipe
Tested on cetos8, all test pass
On 17/11/2021 08:08, Ruediger Pluem wrote:
On 11/17/21 2:39 AM, Mladen Turk wrote:
On 16/11/2021 12:00, Yann Ylavic wrote:
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
Otherwise I'll
On 17/11/2021 08:08, Ruediger Pluem wrote:
On 11/17/21 2:39 AM, Mladen Turk wrote:
On 16/11/2021 12:00, Yann Ylavic wrote:
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
Otherwise I'll revert because I have no way to test it, but I think
that apr_poll_drain_wakeup_pipe() might
On 11/17/21 2:39 AM, Mladen Turk wrote:
>
>
> On 16/11/2021 12:00, Yann Ylavic wrote:
>> On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
>>>
>>> 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
On 16/11/2021 12:00, Yann Ylavic wrote:
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
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.
On 16/11/2021 12:00, Yann Ylavic wrote:
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
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.
On Wed, Nov 10, 2021 at 4:19 PM Yann Ylavic wrote:
>
> 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.
Reverted in 1.7.x, I'll leave it in trunk
On Wed, Nov 10, 2021 at 3:21 PM 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
14 matches
Mail list logo
