Thanks Jukka :) On Wednesday, June 10, 2015 at 4:51:09 PM UTC+8, jj wrote: > > Hi awt, > > in the current pthreads implementation, the main thread is still running > in the main thread of the JS file, and therefore must run asynchronously. > The feature to enable what you describe is > https://github.com/kripken/emscripten/issues/3496 , which will allow > blocking code by moving the main thread to a worker as well. You can use > that bug item to follow the implementation as it progresses. > > Jukka > > 2015-06-10 8:56 GMT+03:00 awt <[email protected] <javascript:>>: > >> Hi jj, >> >> Any update on my question below? >> >> >> On Tuesday, June 9, 2015 at 3:25:31 PM UTC+8, awt wrote: >>> >>> Great news :) Just checking, with the pthread implementation, will we be >>> able to retrieve SDL events in a while loop like the following? >>> >>> 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; >>> } >>> } >>> } >>> >>> On Friday, June 5, 2015 at 12:21:31 AM UTC+8, jj wrote: >>>> >>>> Hello all, >>>> >>>> we've got some really cool news to share! Earlier this week, the >>>> pthreads pull request was merged in to Emscripten upstream, which adds >>>> support for the POSIX threads API to the Emscripten incoming branch. >>>> >>>> The main reason why Emscripten has not had threading support before, is >>>> that the current JavaScript Web Worker specification only allows the >>>> workers (== pthreads to Emscripten) to communicate by passing messages to >>>> each other. In native world, this corresponds to a multiprocess-like >>>> parallel environment, where processes do interprocess pipes to push data >>>> to >>>> each other, or like the MPI API that is used in big computing clusters >>>> that >>>> consist of multiple separate computers that send messages through the >>>> network. Web Workers have followed this approach, and they limit workers >>>> from accessing each other's memory directly. This simplifies parallel >>>> programming greatly, but it is a different paradigm that also limits the >>>> kind of parallel algorithms that one could implement. >>>> >>>> Native threading builds strictly on the assumption that threads can >>>> share memory with each other. This has been the hard and painful part for >>>> JS Web Workers from Emscripten native threading perspective, since shared >>>> memory has not been available. However for more than a year now, there >>>> have >>>> been experiments going on to imagine what such a direct memory sharing >>>> approach for JavaScript Web Workers would look like. This research process >>>> is a collaboration between multiple browser vendors, and you can follow >>>> that discussion here: >>>> https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk/edit#heading=h.a6o4dubw5qla >>>> >>>> , where the SharedArrayBuffer specification is being drafted. Having >>>> direct >>>> shared memory enables more flexible options for parallelism compared to >>>> the >>>> more limited message passing approaches, and this flexibility benefits >>>> both >>>> native JS developers and compilers such as Emscripten. Alongside the >>>> SharedArrayBuffer research, we have been working to add support for >>>> pthreads to Emscripten that backs on to this research, and today we feel >>>> that we are at the point where it makes sense to push the feature to the >>>> incoming branch for everyone to test. >>>> >>>> It should be stressed that this feature is very experimental at the >>>> moment, and the only browser to currently implement support for it is >>>> Firefox Nightly. Being experimental means that there can be any number of >>>> changes made to the specification, which can mean that pages that you have >>>> compiled against it can stop working in Nightly in the future, if the spec >>>> and the implementation changes. We don't want to wait however until the >>>> standard is fixed, before bringing it to Emscripten, because your feedback >>>> will be extremely valuable in shaping the draft further, and that we can >>>> ensure that we get it right, and that the draft that will be proposed for >>>> adoption will be a good one that covers the important Emscripten needs. >>>> So, >>>> if you have some cycles to spare on experimenting with this feature to >>>> give >>>> us feedback, please do, so that we can make sure we don't miss anything! >>>> >>>> What the pthreads support for Emscripten means for developers in >>>> practice: >>>> >>>> - Default build mode is still fully singlethreaded. You should not >>>> see any pthreads-related code "leak in" to your non-pthreads builds ("you >>>> don't pay for what you don't use"). If you do see this, please submit a >>>> bug >>>> report! >>>> - Pass the -s USE_PTHREADS=1 compiler and linker flag to enable >>>> targeting pthreads. This enables the code to call the pthreads API, as >>>> well >>>> as use the GCC built-in lockfree atomics operations and the futex >>>> wait&wake >>>> API. See >>>> https://github.com/kripken/emscripten/blob/incoming/system/include/emscripten/threading.h >>>> >>>> for a list of function calls enabled when targeting pthreads. >>>> - When building with pthreads enabled, the asm.js HEAP is fully >>>> shared between all pthreads, but all objects in handwritten JS code you >>>> write are all thread local (JS objects are not shared between threads) >>>> - Run the compiled output in Firefox Nightly. Remember to deploy the >>>> new output file pthread-main.js alongside the rest of the build outputs, >>>> that contains the "launcher" for pthreads code. >>>> - The implementation should be fairly mature at this point, so don't >>>> be shy to stress it. It has been tested on three large fronts so far: >>>> - The Emscripten unit test suite itself has a section for pthreads >>>> tests: browser.test_pthread_*, see >>>> https://github.com/kripken/emscripten/blob/incoming/tests/test_browser.py#L2517 >>>> - The Open POSIX Test suite has been ported over to build and run >>>> with Emscripten: https://github.com/juj/posixtestsuite/commits/master >>>> . The interface tests should all pass, and hence our implementation should >>>> be POSIX conformant, except for features that Emscripten can't support >>>> (inter-thread signals is one feature that is not available) >>>> - We have been working with Unity to develop multithreading >>>> support to Unity3D WebGL export code, and it is running quite nicely. >>>> Currently we are using this development as a source for scalability >>>> benchmarking like this: >>>> http://clb.demon.fi/emcc/pthreads/webgl_benchmark_pthreads.html >>>> >>>> You can find the documentation for pthreads here: >>>> https://github.com/kripken/emscripten/blob/incoming/site/source/docs/porting/pthreads.rst >>>> >>>> . Emscripten bug tracker also has a new label 'multithreading', and you >>>> can >>>> use that as a filter to follow the multithreading development. See >>>> https://github.com/kripken/emscripten/issues?q=is%3Aopen+is%3Aissue+label%3Amultithreading >>>> >>>> . >>>> >>>> Please do give a go to test how well your code empthreadizes, and let >>>> us know about the issues you are running into. Thanks! >>>> >>>> Jukka >>>> >>>> -- >> 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.
