Thanks Alon :) May I know when will this be ready? I can't wait to try it out :p
On a side note, I understand that Emscripten will soon be having pthread support, I presume this will also go a long way in having synchronous looking code on the web. On Thursday, June 11, 2015 at 6:54:22 AM UTC+8, Alon Zakai wrote: > > 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] <javascript:>> > 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] <javascript:>. >> 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.
