Re: Reentrant GC

[Philippe Verdy <verdy_p@...>]

So Lua alone is not sufficient: the pseudo threads created by coroutine.create have unlimited time resource if they never yield (because the routines are not preempted at all by any scheduler enforcing the time quota) and they also have unlimited access to the same allocator (there's no equivalent to the Luac function lua_setallocator, and in fact no way to create such allocator in Lua, but we could still have the way to have a __alloc metamethod in thread object types that would be used to measure the memory resources requested by the thread in order to limit them by just returning a Boolean authorizing or not the use of the global allocator.

For time resources, there's no solution with Lua coroutines if there's no preemptive mechanism that would force them to yield after a maximum timeslice quantum... For that purpose, we need TRUE threads plus a scheduler, not just cooperating routines.

Si we can't do that in pure Lua with its existing standard library. We need an extension to threads, or we need to use OS threads to instantiate as many separate Lua engines, using a hos application written in C and using the reentrant luac library...

Le mer. 28 nov. 2018 à 13:19, Philippe Verdy <verdy_p@wanadoo.fr> a écrit :

Le mer. 28 nov. 2018 à 12:55, Francisco Olarte <folarte@peoplecall.com> a écrit :

 This is something needed for Lua programs that run threads to implement a web service,

NO, it is not. Lots of people run thread oriented web services without this.

It is not raisonnable at all to run any web service with threads for servicing each concurrent request that can steal unlimited amounts of resources needed by concurrent threads. You need a way to police them or at least ensure that each thread will get an equitable share of resource, i.e. equal share of time and memory, without also exceeding a maximum allowed quantum so that each thread can be sure to also have a minimum share and perform without failing always.

If the web service dies not do that, it is extremely easy to block with a DOS attack. All reasonable requests should then succeed and other requests exceeding their quota will be the only one to fail as expected.

We need limits always because absolutely no server has infinite amounts of resources. So we always need a way to strictly enforce these quota.

With basic Lua threads, we have absolutely no control in any thread that can deliberately use the allocator as much as they want, when they should fail early without causing damages to other competing threads, including hidden internal threads needed for the maintenance and monitoring of the web service itself, or for enforcing the policy, and perform cleanup of failing threads that have exhausted their allowed quota.