On Thu, Jan 11, 2018 at 1:34 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: >> Am 11.01.2018 um 13:02 schrieb Yann Ylavic <ylavic....@gmail.com>: >> >> there a several optimizations and correctness fixes in event/fdqueue.c >> that don't land in worker/fdqueue.c.  > If we had a single, nice build system, I'd be all for it. With the > current state of things, I am not sure it is worth our time to > think about common code that is not in the public API,
At least that'd avoid missing fixes/improvements made in one code and not the other. Not sure fixing twice or more isn't what can consume our time too. > > Making both files the same, might still be worth it since future > enhancements can be copied/patched more easily. And there are not > *that* many people working in this area. Which also suggests code should be centralized IMO, because new comers may not know about the duplication and the need to fix in multiple places. > >> For now things that are event only are not aligned (e.g. timers), but >> ultimately I'd like to have a single fdqueue.[ch] for both MPMs (not >> too far once this patch is applied), that'd certainly help maintenance >> and improvements for both. >> If you agree on this, what would be the best practice/place for the common >> code? > > Making things part of the API has a high price in back porting costs and > not being able to take things away again. I don't mean to make it API, still a private (unix specific/common) thing, something like "os/unix/unixd.c"'s non-AP_DECLARE things. > > Related issues exist in modules too. mod_http2 and mod_proxy_http2 would > like to share. mod_md once had an executable with shared code. > > I eliminated the sharing and the executable rather than having to deal > with that pain. Not ideal, but there is limited time to put into such > things. Yeah, sharing from/between modules (APR_OPTIONAL) is another beast I'd like to avoid here for 2 "unix" MPMs, hence the core non-AP_DECLARE (hidden) proposal maybe. Thanks, Yann.