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].
For more options, visit https://groups.google.com/d/optout.
