 |
lua-l archive |
|
|
||
|
On 12/10/15 10:35 PM, Tim Hill wrote:
It's not the compiler. load() calls back into my code, where I need to get the input. This could initiate a network call, for example.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. —TimWhen 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
And if such a network call requires an yield (wrapped coroutine library, uses yield internally for system tasks), then I'm even more hosed because it'll simply *kill* the thread.
Also the solution with wrapping load() and concatenating the strings manually... probably doesn't work when you're memory constrained.
Look up "OpenComputers". It's affected by all these issues. -- Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.