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] <javascript:>>
> 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] <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.
