[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Yielding across lua_load
- From: Tim Hill <drtimhill@...>
- Date: Mon, 12 Oct 2015 18:35:06 -0700
> On Oct 11, 2015, at 2:20 PM, Soni L. <fakedme@gmail.com> wrote:
>
>
>
> On 11/10/15 04:09 PM, Tim Hill wrote:
>>> On Oct 10, 2015, at 8:07 PM, Soni L. <fakedme@gmail.com> wrote:
>>>
>>>
>>> It's also useful for JIT-tracing to Lua. (easier to reset/use as you don't have to worry about state as much) Especially so when combined with a 3rd party cooperative multitasking library. (you wouldn't be able to keep the other threads going unless you yielded, which would kill the load() and possibly the whole thread as well, because it would error)
>>>
>> If you are worried about compiler overhead, why not spin up a dedicated Lua state on its own thread and use that as an async compile engine? You can shuttle the result back as bytecode and then feed this to lua_load() for very fast load times.
>>
>> —Tim
>>
>>
>>
> When did I say anything about compiler overhead?
>
You mentioned cooperative multitasking, which of course will stall if you call a long non-yieldable API such as lua_load(). Since lua_load() is slow primarily because of the compiler, I assumed this was your concern.
—Tim