On Fri, Jul 14, 2017 at 9:52 PM, Yann Ylavic <[email protected]> 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. 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. 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?
Malware Alert Text.txt
Description: Malware Alert Text.txt
