Nick Kew wrote:
>
> The architectural reason is to pave the way for alternatives to
> mod_unixd, that can either work alongside it (additional functions)
> or replace it entirely (other platforms under simple MPM, or
> alternative security models such as perchild).
I would love to have the logic of thread/process credentials parked in
the arch/{plat}/ module, but can't see how perchild's strategy can
realistically be satisfied by a simple mpm ;-)
In any case, thanks for all the effort on this! It very much mirrors
the "hackery" on win32 that I isolated into mod_win32.c - and we can
surely align such things.
