RFC: Feasibility of a "dynamic module loader" built in to nginx?
mdounin at mdounin.ru
Fri Aug 27 04:19:13 MSD 2010
On Thu, Aug 26, 2010 at 04:14:10AM -0700, Michael Shadle wrote:
> It seems (at least to me) that the past year has seen explosive growth
> in nginx usage and third party module development.
> I believe that for package management, as well as module adoption, it
> would be a definite move in the right direction to be able to load
> modules up on demand instead of having to custom compile nginx with
> the modules you want.
> That allows for module development to be done completely independently
> of nginx, modules to be added/removed, etc, without needing to
> recompile nginx every time.
This was already discussed several times. Just to name a few
reasons why no:
1. Using dynamically linked libraries implies speed penalty.
2. It is likely to cause problems like DLL hell. Even with small
number of carefully selected dynamic libraries nginx currently use
(e.g. openssl) - there are periodically reported problems.
3. It will require to maintain ABI, not something we currently do.
E.g. right now ngx_http_request_s structure changes depending on:
whether pcre library used, http cache enabled, gzip support
enabled, stub status compiled in. Not even talking about local
patches and changes between versions. So things is much more
complex than "0.8.43 needed".
4. Most of us are happy enough with static linkage. Especially
keeping in mind that binary may be upgraded with zero downtime.
More information about the nginx