I’d like to see all those things be documented, and the memory usage in some situations such as transforming etc should be outlined too, ts_lua is now a feature rich plugin, may be heavily used.
在 2014年1月13日，下午2:16，quehan <que...@taobao.com> 写道： > > Further on, users may change TS_LUA_MAX_STATE_COUNT from 2048 to 256 or less. > > > 在 2014-1-13，下午2:09，Yunkai Zhang <yunkai...@gmail.com> 写道： > >> I have discussed with Quehan, in fact, ts_lua can also work with LuaJit. >> >> I think we can add some configruation for ts_lua, so that users can select >> Lua or LuaJit according their business scenario. >> >> >> On Mon, Jan 13, 2014 at 1:43 PM, Yunkai Zhang <yunkai...@gmail.com> wrote: >> >>> HI Quehan: >>> >>> I think Daniel's suggestion is reasonable, maybe we need to reconsider >>> your design if ts_lua may consume too much memory. >>> >>> We can allways put the havy work to ATS, and let ts_lua to handle simple >>> logic, can't we? >>> >>> >>> On Mon, Jan 13, 2014 at 12:12 AM, quehan <que...@taobao.com> wrote: >>> >>>> >>>> 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 1/2 >>>>> 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. >>>> >>>> >>> >>> >>> -- >>> Yunkai Zhang >>> Work at Taobao >>> >> >> >> >> -- >> Yunkai Zhang >> Work at Taobao >
signature.asc
Description: Message signed with OpenPGP using GPGMail
