Revert "Working (but slow) support for pthreads + memory growth (emscripten-core#8365)"

This reverts commit a8164ac.

Author: VirtualTim

emcc.py

@@ -1208,11 +1208,7 @@ def check(input_file):
       if shared.Settings.USE_PTHREADS == 2:
         exit_with_error('USE_PTHREADS=2 is not longer supported')
       if shared.Settings.ALLOW_MEMORY_GROWTH:
-        if not shared.Settings.WASM:
-          exit_with_error('Memory growth is not supported with pthreads without wasm')
-        else:
-          logging.warning('USE_PTHREADS + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271')
-          options.force_js_opts = options.js_opts = True # for JS instrumentation
+        exit_with_error('Memory growth is not yet supported with pthreads')
       # UTF8Decoder.decode doesn't work with a view of a SharedArrayBuffer
       shared.Settings.TEXTDECODER = 0
       options.js_libraries.append(shared.path_from_root('src', 'library_pthread.js'))

site/source/docs/porting/pthreads.rst

@@ -57,8 +57,6 @@ The Emscripten implementation for the pthreads API should follow the POSIX stand
 
 - Note that the function emscripten_num_logical_cores() will always return the value of navigator.hardwareConcurrency, i.e. the number of logical cores on the system, even when shared memory is not supported. This means that it is possible for emscripten_num_logical_cores() to return a value greater than 1, while at the same time emscripten_has_threading_support() can return false. The return value of emscripten_has_threading_support() denotes whether the browser has shared memory support available.
 
-- Pthreads + memory growth (`ALLOW_MEMORY_GROWTH`) is especially tricky, see `wasm design issue #1271 <https://github.com/WebAssembly/design/issues/1271>`_. This currently causes JS accessing the wasm memory to be slow - but this will likely only be noticeable if the JS does heavy work (wasm runs at full speed, so moving work over can fix this). This also requires that your JS be aware that the HEAP* views may need to be updated - use the `GROWABLE_HEAP_*` helper functions which automatically handle that for you.
-
 Also note that when compiling code that uses pthreads, an additional JavaScript file `NAME.worker.js` is generated alongside the output .js file (where `NAME` is the basename of the main file being emitted). That file must be deployed with the rest of the generated code files. By default, `NAME.worker.js` will be loaded relative to the main HTML page URL. If it is desirable to load the file from a different location e.g. in a CDN environment, then one can define the `Module.locateFile(filename)` function in the main HTML `Module` object to return the URL of the target location of the `NAME.worker.js` entry point. If this function is not defined in `Module`, then the default location relative to the main HTML file is used.
 
 Running code and tests