Hello!
On Thu, Feb 6, 2014 at 7:57 PM, Stan Rosenberg wrote:
>
> No, but it appears that nginx is scheduling 'ngx_time_update' in a separate
> thread; i.e., Lua code and 'ngx_time_update' are executed from different
> threads
> within the same process.
It cannot be the case. Nginx is a single-threaded application. The
standard Nginx distribution and most of the 3rd-party modules do not
introduce multi-threading (one notable exception is ngx_pagespeed
AFAIK).
> (Based on my cursory reading of the sources,
> 'ngx_time_update' is synchronized by ngx_time_lock;
This lock is mainly to protect asynchronous signal handlers.
> also the comment says,
> "The time may be updated by signal handler or by several threads."
The Nginx code base has a lot of dead code (and comments) for the
unfinished multi-threading support (that will probably never get done
in nginx 1.x according to Maxim Dounin). So don't get confused :)
>
> The C library we use performs time localization by taking (timezone,
> unix_timestamp) and returning
> (day,hour,minute).
Well, to guard against signal handlers, you can call
ngx_trylock(&ngx_time_lock) with LuaJIT FFI in your Lua code anyway.
To prevent deadlocks, it's better to write an nginx C module to expose
this as an encapsulated Lua API (see my ngx_lua_upstream module for
such an example: https://github.com/agentzh/lua-upstream-nginx-module
).
> Thus, we can't use cached time, but I suppose we could
> use os.date(), os.time(); would it be more performant than calling into the
> C library?
>
No, os.date() and os.time() just calls the libc wrappers under the
hood in both the standard Lua 5.1 interpreter and LuaJIT 2.x. So the
same caveat applies :)
Regards,
-agentzh
