Sweet project. Minecraft and computer building are a sweet combo. I wish that their front page was more enlightening, though.
On 12/10/15 10:35 PM, Tim Hill wrote:
>> 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
>
>
>
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.
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.
