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

>> 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.


Reply via email to