PS: what would be *really* nice is a way to query the current and 'high water mark' stack sizes (only in debug mode, or with a specific build option), to get an idea how much stack a program/thread is using, instead of depending on trial-and-error.
On Tuesday, 11 October 2022 at 17:27:07 UTC+2 [email protected] wrote: > On Tue, Oct 11, 2022 at 12:13 AM Floh <[email protected]> wrote: > >> My C code is still quite stack heavy, because a lot of my code >> essentially uses the stack as per-frame arena allocator ;) But I guess as >> long as there's a compiler/linker option to set the stack size I think it's >> fine. >> >> Will a stack overflow cause a proper runtime error, or will this result >> 'undefined behaviour'? >> > > The plan is to enable `STACK_OVERFLOW_CHECK=2` in debug (-O0) builds > (currently we just use `STACK_OVERFLOW_CHECK=1`). This should give > precise errors at the point of overflow. > > >> On Tuesday, 11 October 2022 at 01:34:07 UTC+2 [email protected] wrote: >> >>> Bumping this discussion because I'm taking a look at landing this once >>> again. >>> >>> In answer to the pthread question: Yes I'm planning on changing the >>> default for both the main thread and pthreads (The plan is to make them the >>> same by default). >>> >>> On Fri, Jul 9, 2021 at 3:24 AM 'Maksim Ivanov' via emscripten-discuss < >>> [email protected]> wrote: >>> >>>> One question: Will this planned change only affect is only for the main >>>> thread? In case there's no change for background threads (e.g., created >>>> via >>>> pthreads), it'll be useful to mention it somewhere. >>>> >>>> On Thursday, May 27, 2021 at 2:01:11 PM UTC+2 jj wrote: >>>> >>>>> ke 19. toukok. 2021 klo 11.27 Floh ([email protected]) kirjoitti: >>>>> > 1 MB is quite certainly ok (but might be a problem for code with >>>>> lots of recursions?), but I think 64 KByte is asking for trouble ;) >>>>> >>>>> Btw, I would recommend you to try how small you can go. I would be >>>>> surprised if you are running into issues with 64KB today. (recursions >>>>> won't increase to this limit, unless the recursing functions have >>>>> locals that have their addresses taken) >>>>> >>>> -- >>>> >>> 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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/emscripten-discuss/d7c00f7e-6bc2-4ae8-ae2d-0353ae4cff80n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/emscripten-discuss/d7c00f7e-6bc2-4ae8-ae2d-0353ae4cff80n%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 [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/7c70d4dc-d14b-4282-9a82-1c1e08393dd0n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/7c70d4dc-d14b-4282-9a82-1c1e08393dd0n%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/218eec81-edce-45b7-b061-a1d57f381d3an%40googlegroups.com.
