FWIW. the C implementation of my scripting language (Io) does this and it worked well. IIRC, it was also used in PL/I. I've ported Io's C Coroutine implementation to emscripten fibers and, so far, it seems to work too. I should write some tests for this when I get a chance. One killer app of small stacks is for servers handling large numbers of sockets. Coroutines make this possible without having to implement buggy and inscrutable stack machines on top of callback hell. With dynamic stack sizes you get scalability without fragility, and without much overhead if the check locations are chosen carefully. Io checks the remaining stack size on each (Io level) block/method activation. As long as emscripten provided the API, developers could judiciously choose where to put the checks in their C code if they choose to compile their app with a smaller stack size. Some emscripten define for the stack size might be helpful there, if there isn't already one.
On Friday, December 16, 2022 at 3:26:30 PM UTC-8 s...@google.com wrote: > On Fri, Dec 16, 2022 at 2:46 PM Steve Dekorte <st...@dekorte.com> wrote: > >> >> How about adding an API like: >> >> Emscripten_extendStackIfNeeded(callback), which could be inserted >> anywhere stack depth might be an issue and would launch another coroutine >> if the stack was almost used up, swap to it, and swap back on return or >> exception? >> > > Interesting, auto-magic, segmented and growable stacks. I don't know of > any platform that does this, but it is an interesting idea. > > I think it could be a lot harder than at first glance. The > biggest problem is that I think it would involve injecting checks > everywhere in the wasm binary where SP is set and everywhere it gets > restored. Each of those locations would likely also need some kind of > extra local state (e.g. previous segment pointer). So maybe not > impossible, but certainly not easy or free of runtime code. > > Luckily, since the execution stack is completely separate and managed by > the VM I don't think it would need to involve any kind of coroutine or > control flow primitive. > > > >> On Tuesday, May 18, 2021 at 1:21:01 PM UTC-7 s...@google.com wrote: >> >>> I have an open PR to reduce the default stack size in emscripten from >>> 5Mb to 1Mb, and we are also considering reducing it even furthur (possibly >>> to 64Kb which is the wasm-ld default, or to 128Kb, which is the musl >>> default): https://github.com/emscripten-core/emscripten/pull/14177. >>> >>> How many folks out there have run into stack limits with the current >>> limit of 5Mb? How many folks are worried they would run into limits if we >>> reduce the default to 1Mb, 128Kb or 64Kb? Would those who feel they need >>> more stack be OK adding `-sTOTAL_STACK` to their link command to request a >>> higher limit? (feel free to respond there, or on the issue above). >>> >>> cheers, >>> sam >>> >> -- >> > You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to emscripten-disc...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/4444d68e-5d77-448c-9e97-2cf11e8f0e09n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/4444d68e-5d77-448c-9e97-2cf11e8f0e09n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/d3e50a8a-713e-4ac7-abe2-c5ddd781d702n%40googlegroups.com.
