https://bz.apache.org/bugzilla/show_bug.cgi?id=63900
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|REMIND |--- Status|RESOLVED |REOPENED --- Comment #3 from [email protected] --- (In reply to Christophe JAILLET from comment #1) > Hi, > > The line above is: > status = ap_mpm_query(AP_MPMQ_IS_ASYNC, &async_mpm); > > > As said in the comment: "some MPMs do not implement this", so if an "error" > is reported by a MPM, we consider that it can not process async connections. > > The call chain is: > ap_mpm_query > --> ap_run_mpm_query > --> function defined by 'ap_hook_mpm_query' in each MPM > > Theses functions return in rv, either APR_SUCCESS or APR_ENOTIMPL. > So it is not really an error. > > For example,: > worker_query: rv = APR_ENOTIMPL > event_query: rv = APR_SUCCESS > > > So, this is not strictly speaking error handling, but fallback to a default > behavior if a functionality is not explicitly supported. Though they return in rv, but some do return APR_EGENERAL. For example, the ap_mpm_query does not preserve APR_ENOTIMP. It does return APR_EGENERAL. So what you said cannot hold. AP_DECLARE(apr_status_t) ap_mpm_query(int query_code, int *result) { apr_status_t rv; if (ap_run_mpm_query(query_code, result, &rv) == DECLINED) { rv = APR_EGENERAL; } ... } I would suggest more add the detailed error handling, like if (status != APR_SUCCESS && status != APR_EGENERAL) { /* some MPMs do not implemnent this */ async_mpm = 0; status = APR_SUCCESS; } You do miss the cases for the declined query. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
