RFC: Feasibility of a "dynamic module loader" built in to nginx?

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

Maxim Dounin

More information about the nginx mailing list