Re: Deep resume and yield for nested coroutine

[William Ahern <william@...>]

On Tue, May 14, 2019 at 07:09:46PM +0200, Philippe Verdy wrote:
> Isn't it possible to just compile Lua with a C compiler targetting
> WebAssembly <https://webassembly.org/>?

FWIW, WebAssembly is hostile to coroutines and stackful coroutines in
particular. It does not make a good target for Lua, Go, or similar languages
that reify the logical execution stack. They require an entire extra layer
of indirection which will always make them second-class citizens in WASM.

That said, you can of course compile the PUC Lua VM to WASM today, and
people have. I don't see much value in it, but nothing is stopping you. Give
it a try and many things will become clear in ways that would be difficult
to communicate.

> It is more or less an hypervisor implemented in Javascript used to boot a
> Linux-like kernel, and already working across 4 major browsers (Firefox,
> Chrome/Chromium, Safari and IE) on Windows, MacOSX and Linux (with the
> builtin Javascript engines of these browsers) ?
> Did someone try it ? Could Lua be successfully compiled with its toolchain
> (which includes the C compiler and most shell and dev tools from Linux) ?
> I cannot be so bad in perfomance, given the demos including games made with
> Unity. The mini Linux kernel run by Webasembly boots really fast and
> applications made with it are also very small to download. Behind the
> scene, there's the LLVM engine, but we've seen Mozilla and Google working
> to boost WebAssembly. And soon Microsoft will abandon Edge to rebuild it
> from the Webkit/Chromium base, so it will hopefully support WebAssembly)
> 
> 
> Le mar. 14 mai 2019 à 17:47, Francisco Olarte <folarte@peoplecall.com> a
> écrit :
> 
> > I skipped the first message but:
> >
> > On Tue, May 14, 2019 at 5:22 PM pocomane <pocomane_7a@pocomane.com> wrote:
> > > Il gio 9 mag 2019, 11:33 pocomane <pocomane_7a@pocomane.com> ha scritto:
> > >> The whole lua script is wrapped in a coroutine, and the browser resume
> > it until it goes to the 'dead' state. Ideally I can wrap browser actions in
> > some lua function that yields. On the javascript side there will be
> > something that parses the yielded values.
> > >> This does not works when the "Browser interaction api" is called from a
> > sub-coroutine created in the lua code. Or, at least, I need to propagate
> > the "Yielding" to the parent coroutine, and the "Resuming" to the child one
> > [2].
> >
> > Why do you need this? I did a similar thing, more or less:
> > - when you start the lua stuff, you create a corourine and start it.
> > - When lua code wants to call API it calls a routine published in the
> > interpreter which yields a special token ( a lightuserdata, or the
> > funcion per se ) plus the function it wants to call and the
> > parameters, control returns to C.
> > - C records the coroutine which yielded somewhere ( registry? ), and
> > calls the API.
> > - Api comes back, recover the suspended coroutine from where you
> > stored it and return it.
> >
> > If API has created a coroutine, the main one is already "dormant", and
> > the child, which will be woken up on API return, is the responsible of
> > returning to it.
> >
> > IIRC I also had to send API messages ( and call lua from message
> > handlers ), and what I did was to pass a "usertoken" in the message,
> > which was a pointer to a heap allocated pointer to the (main) lua
> > state and use it as a lightuserdata key in the registry to the
> > coroutine, so the api code, when invoked on message return, could
> > recover the state pointer, recover the coroutine from the registry,
> > free the usertoken and resume the correct coroutine.
> >
> > I do not have the code handy, and it was tailored for the specific
> > host, but I do not remember having problems.
> >
> > > I just want to fully stop the lua VM, to process some data outside lua,
> > and then to restart the VM exactly where it did stop. To do this
> > transparently with the proposed code, a lot of auxiliary code is required,
> > e.g. to decide if perform a `nestresume` or a normal one, to handle errors,
> > to wrap the standard coroutine functions, and so on.
> >
> > I do not think you need to resume the main coroutine, just resume the
> > one calling the API.
> >
> > Francisco Olarte.
> >
> >