You're mangling your buzzwords. Lua doesn't need a global interpreter lock because it already is thread-safe.

Lua also starts up far faster than Python, and has a vastly smaller overhead for loading code (which is easily verified).

C indeed makes that stuff vastly cheaper, but Lua also has a much clearer C migration path than Python or Ruby - it was designed for embedding.

Also, Python and (especially!) Ruby are slow, they just spend much of their execution time calling out to string libraries in carefully-optimized C.

Uh, no. Lua is thread-safe in the sense that you can use multiple Lua states in the same program. That is exactly what Lua lanes and the other package are doing. And what is described in the Programming in Lua book by Robert I.

But you can't access the same lua_State from 2 C threads, and you can't share data structures between 2 separate lua_States -- you would have to serialize all your data structures the message-pass between them. So if Lua had an interpreter lock, it would enable a Lua-threading library which Python and Ruby have. The lock would just belong in the lua_State and not be an actual C global. (not saying it should add this; just pointing out the difference)

You're use of the word "slow" doesn't have any meaning. What I meant is that Python and Ruby are not slow in the sense that you couldn't write "scalable" CGIs style with them in Hipp's style IF they didn't have horrendous startup time. That is, once the interpreter is started, you can do a LOT of work in 50ms of Python or Ruby (which is exactly what sites that serve billions of page view a month are doing). It's just that loading the interpreter can take upwards of 100ms with a lot of libraries. So with those languages, people use persistent servers rather than what Hipp is advocating.

In Lua you could have a persistent C program and initialize a new lua_State for every request. That would be the moral equivalent of CGI, without the fork(), since all the state is wiped between every request. But, getting back to the original point, that wouldn't retain the ease of administration that Hipp wants because it wouldn't work with inetd.

> Lua doesn't need a global interpreter lock because it already is thread-safe.

The default implementation of the Lua interpreter is not thread safe: http://lua-users.org/wiki/ThreadsTutorial

FWIW there are numerous libraries available for OS threads in Lua. Some are low-level, directly binding the OS threading API[1], some are high-level[2], supporting message passing and atomic counters, etc.

[1]: https://github.com/Neopallium/lua-llthreads [2]: http://kotisivu.dnainternet.net/askok/bin/lanes/

Right, but this is different than Python and Ruby's threading, where threads can share state because they have a global interpreter lock. Lua has no such thing so both of those packages have to use message passing, which I think is good but not convenient in a lot of cases. Even though they are using threads, there is one Lua state per thread, so your threads have to serialize everything before communicating.

As mentioned in the PIL book, they are better termed "Lua Processes" even though they are implemented using OS threads.

Does Lua not have the startup time issues of Python/Ruby? If it does, then to counteract the lack of threads you'd probably use a coroutine-based system like gevent and Python's greenlets.

  matthew@rusticanum:~$ time python2.6 -c 'print("hello world")'
  hello world
  
  real	0m0.027s
  user	0m0.024s
  sys	0m0.004s
  
  matthew@rusticanum:~$ time lua -e 'print("hello world")'
  hello world
  
  real	0m0.005s
  user	0m0.000s
  sys	0m0.000s

Nevertheless, what you describe is practically how Tir works: http://tir.mongrel2.org/

That's a good comparison to make, but once you have a Python program or Ruby program importing 20 packages, each with several modules, then it gets really slow. Like 100-500ms, which is more work than the "real" work of a handling many HTTP requests. Bad packages can do arbitrary computation at import time.

To be fair, I haven't run any Lua programs with 20 packages... AFAIK Lua didn't have a module system until Lua 5, and it's not as capable as Python or Ruby's.

No, it doesn't. It also has vastly more efficient coroutines.