It's in incoming now, and yes, it allows another way to get synchronous code. But it will be a while though before browser support is common (only Firefox Nightly has it so far).
On Thu, Jun 11, 2015 at 4:54 AM, awt <[email protected]> wrote: > 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]> 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. > -- 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.
