advice on module design

Peter Leonov gojpeg at
Sat Mar 27 14:41:28 MSK 2010

Hi Manilo,

On 27.03.2010, at 0:07, Manlio Perillo <manlio.perillo at> wrote:

> Hash: SHA1
> Hi.
> As I wrote in a previous message, in an effort to improve the WSGI
> module, I have moved Python support to a separate module:
> When the module is included in Nginx, the Python interpreter will be
> initialized unconditionally.
> The new `ngx_http_wsgi module` now use the "module init" callback
> function, to do its own Python specific initialization (in old version
> this was done in the HTTP post configuration callback), since this is
> the only place where we know the `ngx_python_module` has been fully
> initialized.
> A different solution is to define a custom "python" directive in the
> `ngx_python_module`, and initialize the Python interpreter here only  
> if
> directive is specified in configuration file.
> The disadvantage is that:
> * I can no more use multiple directives for Python configuration
>  (not a big deal)
> * The `ngx_http_wsgi_module must` can no more assume the Python
>  interpreter is initialized (again, not a big deal)
> What is the best solution?
In ngx_http_js_module it works like the second variant, which is  
copied from ngx_http_perl_module. Some code that knows about blablabla  
module calls ngx_blablabla_init_interpreter() at the exact moment it  
going to do something blablabla-related ;) In its turn  
ngx_blablabla_init_interpreter() does really init interpreter or just  
return the already existed and cached in some global/static variable.  
All this modules (perl and javascript) use one global interpreter for  
all requests.

Am thinking this is not very sexy approach but a simple and reliable  

Gest regards,

> Thanks  Manlio
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> It8AoJdZeYEY2s89FWvhKt8gl2+lbCo1
> =PYew
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at

More information about the nginx-devel mailing list