Hi Yann and Ruediger, 2c from a mpm-event newbie inline:
2017-06-30 13:33 GMT+02:00 Yann Ylavic <[email protected]>: > On Fri, Jun 30, 2017 at 1:20 PM, Ruediger Pluem <[email protected]> wrote: > > > > On 06/30/2017 12:18 PM, Yann Ylavic wrote: > >> > >> IMHO mod_ssl shoudn't (BIO_)flush unconditionally in > >> modssl_smart_shutdown(), only in the "abortive" mode of > >> ssl_filter_io_shutdown(). > > > > I think the issue starts before that. > > ap_prep_lingering_close calls the pre_close_connection hook and modules > that are registered > > to this hook can perform all sort of long lasting blocking operations > there. > > While it can be argued that this would be a bug in the module I think > the only safe way > > is to have the whole start_lingering_close_nonblocking being executed > by a worker thread. > This makes a lot of sense and I agree, but at the same time I feel that it would be really great not to move lingering close responsibilities away from the listener. As far as we know mod_ssl is the only one that shows this "buggy" behavior, would it make sense to attempt to "fix it" now and postpone the decision about pushing start_lingering_close_nonblocking to a worker thread? > Correct, that'd be much simpler/safer indeed. > We need a new SHUTDOWN state then, right? > IIUC in each case that the listener calls start_lingering_close_nonblocking we'd need to set the connection to SHUTDOWN, check if there is a free worker and push2worker the connection to it right? Thanks! Luca
