As we know, one request can be processed by different threads in ats, and I want to transimit data at different stages, so I have to create serveral Lua states for concurrency.
I also want to implement many features with ts-lua, such as transform, intercept, fetcher, tcp and others. No matter the limit is 2GB or 1GB, I don't think it is enough for all LuaStates in one process, as gc is controlled by Lua itself. 在 2014-1-12，下午10:28，Daniel Gruno <rum...@cord.dk> 写道： > On 01/12/2014 03:35 AM, quehan wrote: >> I think it is 1G for all lua_States in one process. >> >> >> 在 2014-1-12，上午1:39，James Peach <jpe...@apache.org> 写道： >> >>> On Jan 10, 2014, at 8:16 PM, quehan <que...@taobao.com> wrote: >>> >>>> hi, all: >>>> >>>> As far as I know, LuaJIT can only use 1G memory at most, so ts-lua is >>>> suggested to use Lua rather than LuaJIT. >>> >>> That is 1G for each lua_State, right? Since you are allocating 2048 states, >>> have you found this to be a problem in practice? >>> >>>> >>>> I found Lua5.2 is very different with Lua5.1, so Lua5.2 is not supported >>>> now, and I didn't have time to fix it yet, may be I will fix it later. >>>> >>>> >>>> <bla bla bla> > > IIRC, the limit is 2GB, not 1GB, but why on earth would you ever, EVER > want to have a state with 2GB of allocated Lua objects? Your code would > slow to a grinding halt! If you need to allocate more with JIT, you use > FFI and call (ts)malloc/free, it would be folly to try to manage > anything this large with native Lua objects. Ideally, you would handle > 'control' data within Lua and 'real' data within TS, maybe, AT MOST ½MB > of data per state for some transformation or advanced math or whatever. > > I'm sorry to say, but if there ever comes a time where you need to > allocate more than 2GB, or, heck, even 1GB, inside Lua itself, then > you're doing something really wrong. Lua should be doing the business > logic while TS does the heavy resource work, it should never be the > other way around. > > With regards, > Daniel.
