[rnmmrnm]

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?

[interroboink]

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]

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.

[Dylan16807]

If you find a debugger that can't ruin a function's local variables then that debugger sucks.

[rnmmrnm]

obviously, but i'm not so keen to turn it into a pre-emptive scheduler either lol.

[rnmmrnm]

reading beyond the first paragraphs, I see this practically what he advocates to do :P

[sanxiyn]

She, not he. kyren is a woman.

[rnmmrnm]

Terribly sorry!