I thought about this some more and ended up removing the YIELDLIST. The assertions it adds are useful in some sense, but they complicate the mental model, and fixing the issue here makes them even more complicated (adds another difference between sleep and sleep_with_yield). We may need to revisit adding something like the YIELDLIST in the future, if people have problems with the emterpreter, but so far actually the issues have been mostly the reverse, with the YIELDLIST being too annoying.
- Alon On Fri, Jun 5, 2015 at 10:53 AM, awt <[email protected]> wrote: > Your suggestion to not warn for emscripten_sleep_with_yield while still > keeping the warning for emscripten_sleep sounds good to me :) I agree with > you primarily that this problem applies to a multi-threaded environment on > the desktop as well. > > In your example below, the value of x could have been changed by another > thread anyway and compilers typically do not insert a warning for such > scenarios. The onus is on the developer to manage his global variables > carefully in a multi-threaded environment. However, considering the lack of > locks in the Javascript world, it might be clearer to draw a distinction > between sleep and a sleep with yield. > > Just my two cents :) > > On Saturday, June 6, 2015 at 1:10:30 AM UTC+8, Alon Zakai wrote: >> >> The reason for the yield list is more conceptual than solving a practical >> problem. Consider this code >> >> int x = 10; >> >> int func() { >> printf("%d\n", x); >> emscripten_sleep(5); >> printf("%d\n", x); >> } >> >> Normally, we would expect the same value to be printed twice :) But if >> code runs during the sleep, it is breaking how C and C++ code normally >> runs, someone could modify that global variable. It isn't "normal" for an >> event to run in the middle there, and it might not even be valid if the >> function on the stack has taken a lock, for example. The yieldlist is meant >> to warn about this type of situation. But yes, as you said, the emterpreter >> is able to make things work, from its perspective, it is just that the >> program might have not expected this and have bugs. >> >> Perhaps this is too paranoid, though. This isn't a new problem compared >> to having multiple threads. >> >> One option is for us to make emscripten_sleep_with_yield automatically >> allow all code to run during the sleep, without needing a yield list, while >> emscripten_sleep (and other sync operations) would still warn. Thoughts? >> >> - Alon >> >> >> >> On Fri, Jun 5, 2015 at 10:00 AM, awt <[email protected]> wrote: >> >>> Unfortunately, just a simple mouse over the SDL2 window would require >>> the following functions to be added to the yield list at least: >>> >>> -s NO_EXIT_RUNTIME=1 -s EMTERPRETIFY=1 -s EMTERPRETIFY_ASYNC=1 *-s >>> EMTERPRETIFY_YIELDLIST=\"['_Emscripten_HandleMouseMove', >>> '_Emscripten_HandleMouseFocus', '_SDL_SendMouseMotion', >>> '_SDL_UpdateMouseFocus', '_SDL_PrivateSendMouseMotion', >>> '_SDL_GetWindowSize', '_SDL_EventState', '_Emscripten_HandleFocus', >>> '_SDL_PushEvent', '_SDL_GetTicks', '_SDL_RendererEventWatch', >>> '_SDL_PeepEvents']\"* -s ASSERTIONS=1 --preload-file image.png -O3 >>> --profiling >>> >>> That will be 12 functions minimally and I gave up halfway thru. When you >>> suggest that we queue the events for after the yield, are you saying that >>> we can run each event handler after the code resumes from the sleep? >>> >>> Perhaps I don't really understand the yield assertions, why do we need >>> them when all the SDL2 functions are already interpreted? Wouldn't the >>> interpreter be able to push and pop the interpreted functions off the stack >>> without the need to check if the functions are inside a yield list? >>> >>> On Saturday, June 6, 2015 at 12:30:44 AM UTC+8, Alon Zakai wrote: >>>> >>>> I think it would be just the mouse handler function, and a key handling >>>> function, basically one for each event you need? Hopefully no other methods >>>> would need to be added. Unless the handlers immediately call other code >>>> instead of queuing. >>>> >>>> The only other approach is to not run compiled code while yielding, for >>>> example to handle the events in JS and queue them for after the yield. >>>> Perhaps we could add an option for that, but I worry it could be confusing. >>>> >>>> Maybe another option is to let people disable the yield assertions. >>>> Again, though I worry this could be confusing. >>>> >>>> - Alon >>>> >>>> >>>> On Fri, Jun 5, 2015 at 2:19 AM, awt <[email protected]> wrote: >>>> >>>>> Thanks for your reply Alon. You are right, I am using >>>>> emscripten_sleep_with_yield in the following manner: >>>>> >>>>> for (;;) >>>>> { >>>>> SDL_Event event; >>>>> while (SDL_PollEvent(&event)) { >>>>> EventHandler(0, &event); >>>>> } >>>>> emscripten_sleep_with_yield(100); >>>>> } >>>>> >>>>> The aim is to simulate a message loop in my application while still >>>>> consuming mouse and keyboard events from the user. Going by the YIELDLIST >>>>> method, I will end up with a large number of internal SDL functions in my >>>>> list which is hard to maintain. There will also be other proprietary >>>>> functions that I will need to add as well. >>>>> >>>>> In SDL1, we had emscripten_SDL_SetEventHandler that could abstract >>>>> away the SDL internal functions but that function seems to be missing from >>>>> the Emscripten SDL2 port. >>>>> >>>>> Do you have any suggestions on how we can reduce the number of >>>>> functions in the YIELDLIST or another method to get around this? >>>>> >>>>> On Friday, June 5, 2015 at 12:55:59 AM UTC+8, Alon Zakai wrote: >>>>>> >>>>>> Based on the stack trace, that method is called from a JavaScript >>>>>> event handler, I guess during a sleep. To enable that, you need to add >>>>>> the >>>>>> method to the YIELDLIST, which is a list of methods that are ok to call >>>>>> during sleep. >>>>>> >>>>>> The only other option is for emscripten to automatically delay the >>>>>> event until after the sleep, I'm not sure if we considered doing that or >>>>>> not, but in general it seems like it would make events show up later than >>>>>> expected. >>>>>> >>>>>> - Alon >>>>>> >>>>>> >>>>>> On Thu, Jun 4, 2015 at 3:54 AM, awt <[email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I created a simple SDL2 application with the following pseudo code: >>>>>>> >>>>>>> 1. SDL_Init with SDL_INIT_VIDEO >>>>>>> 2. SDL_CreateWindow >>>>>>> 3. SDL_CreateRenderer >>>>>>> 4. IMG_LoadTexture >>>>>>> 5. SDL_QueryTexture >>>>>>> >>>>>>> After this, I try to start up my own message loop in the following >>>>>>> manner: >>>>>>> >>>>>>> for (;;) >>>>>>> { >>>>>>> while ((1<=SDL_PeepEvents(&e, 1, SDL_GETEVENT, SDL_QUIT, >>>>>>> SDL_LASTEVENT))) >>>>>>> { >>>>>>> //If user closes the window >>>>>>> switch (e.type) >>>>>>> { >>>>>>> case SDL_QUIT: >>>>>>> { >>>>>>> cout << " SDL_QUIT received!!!"; >>>>>>> quitApp(); >>>>>>> return; >>>>>>> } >>>>>>> default: >>>>>>> break; >>>>>>> } >>>>>>> } >>>>>>> emscripten_sleep(10); >>>>>>> } >>>>>>> >>>>>>> But when I click on the window, I get the following assert: >>>>>>> >>>>>>> Uncaught abort(-12) at Error >>>>>>> at jsStackTrace >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:1325:13) >>>>>>> at stackTrace >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:1342:22) >>>>>>> at abort >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:33928:44) >>>>>>> at Array._Emscripten_HandleMouseFocus >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:22365:54) >>>>>>> at dynCall_iiii >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:31705:40) >>>>>>> at Object.Runtime.dynCall >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:426:39) >>>>>>> at Object.handlerFunc >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:1943:38) >>>>>>> at HTMLCanvasElement.jsEventHandler >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:1846:24) >>>>>>> This error happened during an emterpreter-async save or load of the >>>>>>> stack. Was there non-emterpreted code on the stack during save (which is >>>>>>> unallowed)? You may want to adjust EMTERPRETIFY_BLACKLIST, >>>>>>> EMTERPRETIFY_WHITELIST, or EMTERPRETIFY_YIELDLIST (to consider certain >>>>>>> functions ok to run during an emscripten_sleep_with_yield). >>>>>>> This is what the stack looked like when we tried to save it: 1,Error >>>>>>> at jsStackTrace >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:1325:13) >>>>>>> at stackTrace >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:1342:22) >>>>>>> at Object.EmterpreterAsync.handle >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:8744:40) >>>>>>> at _emscripten_sleep >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:8767:24) >>>>>>> at emterpret >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:13021:6) >>>>>>> at Object.emterpret >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:12504:4) >>>>>>> at resume >>>>>>> (file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:8737:17) >>>>>>> at >>>>>>> file:///C:/work/git/SDLPrototypes/EventHandling/src/build/EventHandling.js:8770:11 >>>>>>> >>>>>>> I find this strange because I am compiling with the following linker >>>>>>> flags: >>>>>>> -s NO_EXIT_RUNTIME=1 -s EMTERPRETIFY=1 -s EMTERPRETIFY_ASYNC=1 -s >>>>>>> ASSERTIONS=1 --preload-file image.png -O3 -g3 >>>>>>> >>>>>>> These are my compiler flags: >>>>>>> -s USE_SDL=2 -s USE_SDL_IMAGE=2 -s ASSERTIONS=1 -O3 -g3 -D_DEBUG_ >>>>>>> -D_DEBUG >>>>>>> >>>>>>> Since I did not specify any whitelist, I presume that all the code >>>>>>> in my generated javascript should already be emterpreted. But somehow, >>>>>>> _Emscripten_HandleMouseFocus isn't able to handle async states properly >>>>>>> as >>>>>>> this leads to a -12 abort. >>>>>>> >>>>>>> Does this mean that I have to manually add all "handle mouse" >>>>>>> functions into the white or yield list? Or is there a better way around >>>>>>> it? >>>>>>> I am on emsdk 1.30.0. >>>>>>> >>>>>>> -- >>>>>>> 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]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> 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]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> 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]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
