These limitations are familiar, but in the future, building on the upcoming pthreads branch, we should be fortunate enough to fix/work around all of these blockers!
Real CPU-conserving sleep is already implemented in the pthreads branch at: https://github.com/juj/emscripten/blob/pthreads/system/lib/pthread/library_pthread.c#L245. It looks a bit odd since it has to wait in slices in order to stay cooperatively responsive to interruptions. Also with the pthreads branch, it will be possible to get JS events proxied into C code even though the C code is running an infinite loop. The way this can be done is that in the pthreads branch the Emscripten HEAP is a SharedArrayBuffer (from this spec: https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk/edit?usp=sharing ), so multiple threads can read and write to it simultaneously. The JS events are pushed onto the Emscripten HEAP, and the C side pthread/main thread can then read the event off of its HEAP directly in asm.js/C land. However I don't yet have that in a working condition since it requires a moderate amount of refactoring of the PROXY_TO_WORKER option, because there will most likely be a JavaScript spec limitation that the main JS thread will not be able to access SharedArrayBuffer objects. As a result we must set up a second intermediary worker thread to do the JS event -> C event passing into the SharedArrayBuffer. One of the overall goals of the pthreads branch is to be able to run (single or multi-threaded) infinite looping code so that one doesn't need to do the synchronous->asynchronous transformation. I'll be sure to post back once I've been able to make the branch compatible with the PROXY_TO_WORKER option, so you can try it out! 2015-05-05 0:16 GMT+03:00 Boris Gjenero <[email protected]>: > Today I learned about the possibility of running synchronous code in a web > worker, via --proxy-to-worker. A simple SDL 2 example which displays > animation worked with emscripten_set_main_loop() replaced by an infinite > loop. However, two problems make this impractical. I just want to make sure > these are still unavoidable JavaScript limitations. > > There seems to be no way to get events when running in an infinite loop, > so there is no way to get input. If you want input, you have to regularly > return to the browser event loop, just as if you were not running in a > worker, and you won't be able to avoid using Emterpreter-Async or Asyncify. > > There also seems to be no way to sleep, so you have to busy wait instead. > A function which schedules another function to run at a later time cannot > be used as a general replacement for a function which waits and returns. > So, you again run into the same limitations as when not running in a worker. > > -- > 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.
