At a time when nginx (at least the commercial version) is starting to emphasize nginx+javascript instead of nginx+lua, it's interesting to see a project try the opposite approach: take the nginx+lua combination and replace nginx with more lua.
I wouldn't make too much of that. For all we know it could be running on a Raspberry Pi. It might be slow, but their public site is not the way to tell.
Recently I was made aware of one gotcha of using lua/luajit from multiple threads (with lua/luajit vm context per thread). And the problem is simply due to underlying libc thread safety which I (finally) understood why Python did with it's global (per all VM's in the process) lock.
Simply - things like getenv() are not-thread safe, and not guaranteed to be if there is setenv(). Not lua/luajit's fault, but might be seen as such (higher level language, supposed to guard folks from things like that).
It suddenly changed my thinking of VM's in general and their interaction with the standard library and the OS.
(One can say maybe every function from libc/msvcrt/etc. must be thread-safe, but then there are things like errno, or getenv() returning pointer).
15 comments
[ 3.1 ms ] story [ 48.9 ms ] threadIf I were looking for a stand-alone -no nginx- solution: Why would I use this instead of lev[1] or luvit[2] ?
[1] https://github.com/connectFree/lev/
[2] https://luvit.io/
[3] http://tarantool.org
I wonder how nice they are to use compared to threads, or even to node-style CPS.
Simply - things like getenv() are not-thread safe, and not guaranteed to be if there is setenv(). Not lua/luajit's fault, but might be seen as such (higher level language, supposed to guard folks from things like that).
It suddenly changed my thinking of VM's in general and their interaction with the standard library and the OS.
(One can say maybe every function from libc/msvcrt/etc. must be thread-safe, but then there are things like errno, or getenv() returning pointer).
[1] http://www.reddit.com/comments/63hth/ask_reddit_which_oss_co...