Hi Yann,

2017-07-21 1:05 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>:

> On Fri, Jul 14, 2017 at 9:52 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
> >
> > So overall, this patch may introduce the need for more workers than
> > before, what was (wrongly) done by the listener thread has to be done
> > somewhere anyway...
>
> That patch didn't work (as reported by Stefan Pribe) and I now don't
> feel the need to debug it further, see below.
>
> >
> > Finally, I think there is room for improvements like batching
> > shutdowns in the same worker if there is no objection on the approach
> > so far.
>
> That's the way to go IMO, here is a new patch which is much simpler
> and effective I think.
>

It is indeed much simpler to follow even for people like me with not enough
experience in mpm-event's code :)


> The idea is that when nonblocking is required (i.e. in the listener),
> connections to flush and close are atomically pushed/popped to/from a
> chain (linked list) by the listener/some worker.
>
> So start_lingering_close_nonblocking() simply fills the chain (this is
> atomic/nonblocking), and any worker thread which is done with its
> current connection will empty the chain while calling
> start_lingering_close_blocking() for each connection.
>
> To prevent starvation of deferred lingering closes, the listener may
> create a worker at the of its loop, when/if the chain is (fully)
> filled.
>

IIUC the trick is to run "(have_idle_worker && push2worker(NULL) ==
APR_SUCCESS)" that reserves a worker that in turn eventually checks the
defer_linger_chain as part of its new code. This also seems sto leverage
workers_were_busy that will prioritize lingering closes over ka connections
right? (or at least try to)



> While the previous patch potentially induced some overhead in the
> number workers and thread contexts switches, I think this new one much
> better in this regard.
>
> What do you think of it?
>

I like it, from a first look I'd +1 it but as said above I am not really
authoritative for mpm-event's code :)

Let's see how Stefan's tests go!

Thanks for this work.

Luca

Reply via email to