[HN Gopher] Piccolo - A Stackless Lua Interpreter
___________________________________________________________________
Piccolo - A Stackless Lua Interpreter
Author : vvoruganti
Score : 116 points
Date : 2024-05-02 17:38 UTC (5 hours ago)
(HTM) web link (kyju.org)
(TXT) w3m dump (kyju.org)
| rnmmrnm wrote:
| A bit off topic: I just wrote a bunch of lua C debug api code
| (lua_sethook) to pre-emptively run and context-switch multiple
| lua "coroutines" (well not so "co").
|
| Is this library offering a lua implementation more well-designed
| for this use-case? I got all this code to unload the coroutine
| stack to store and and reload it before continuing it later. Does
| having C bindings to this library makes sense?
| rnmmrnm wrote:
| reading beyond the first paragraphs, I see this practically
| what he advocates to do :P
| interroboink wrote:
| I think yes?
|
| My understanding is that the "stackless" concept here means
| that it does not store its execution state in the "C runtime
| stack" (or Rust, in this case).
|
| So, there is some blob of memory describing that info, managed
| by Piccolo, rather than it residing on the "real" OS execution
| stack.
|
| In particular, for call chains like: Lua -> C -> Lua -> C (or
| so), it is normally hard to save/restore the "C" parts of that
| chain, since you need to peek into the not-normally-accessible
| and platform-specific C runtime stack details. I wonder: how
| are you doing it in your system?
|
| In Piccolo, I imagine it would be easier, since even the "-> C
| ->" portions of the stack are being managed by Piccolo, not the
| base C runtime. I don't know what the APIs to access that stuff
| actually look like, though.
|
| Aside: have you looked at Pluto/Eris for Lua serialization of
| coroutines?
|
| ----
|
| _EDIT_ Yes, it seems like the section The "Big Lie" is right
| up your alley (:
| rnmmrnm wrote:
| Well the only thing that's really itching me is the fact that
| the whole lua debug.* section is documented as
|
| >You should exert care when using this library. Several of
| its functions violate basic assumptions about Lua code (e.g.,
| that variables local to a function cannot be accessed from
| outside; that userdata metatables cannot be changed by Lua
| code; that Lua programs do not crash) and therefore can
| compromise otherwise secure code (from the manual)
|
| kinda creeps me out.
| qudat wrote:
| I love the design of the website, nice work!
| klaussilveira wrote:
| I wonder if a Rust reimplementation of Lua will, one day, be
| faster than LuaJIT.
| animaomnium wrote:
| Clearly that isn't the case, surely Mike Pall would have heard
| of it, when he brought back LuaJIT from the future, that is.
| PhilipRoman wrote:
| Good point, it is well known that speed of machine code varies
| greatly depending on what language was used to generate it.
| Jokes aside, I really don't see a point in this. The safety
| guarantees of Rust are thrown out of the window the second you
| call dynamically generated code.
| wesamco wrote:
| I love how there are many Piccolo REPLs embedded in the article
| and interleaved with the paragraphs.
|
| Piccolo looks amazing, I got a perfect use case for it, and I'm
| excited for when I get the chance to use it, thank you for
| working on it.
| jxyxfinite wrote:
| Beautiful website! Would love to learn more about the stack
___________________________________________________________________
(page generated 2024-05-02 23:00 UTC)