Synchronous xhr requests running in a thread cause a deadlock

[VirtualTim]

Using the Emscripten Fetch API, or xhr directly both cause a deadlock when run in synchronous mode in a thread.

Example code:

void fetch_xhr() {
  EM_ASM_({
    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'https://emscripten.org/_static/Emscripten_logo_full.png', false);
    xhr.send();
    console.log("state:" + xhr.readyState + ", status:" + xhr.status);
  });
}

void fetch_emsc() {
  emscripten_fetch_attr_t attr;
  emscripten_fetch_attr_init(&attr);
  strcpy(attr.requestMethod, "GET");
  attr.attributes = EMSCRIPTEN_FETCH_LOAD_TO_MEMORY | EMSCRIPTEN_FETCH_SYNCHRONOUS;
  emscripten_fetch_t *fetch = emscripten_fetch(&attr, "https://emscripten.org/_static/Emscripten_logo_full.png");
  std::cout << "status: " << fetch->status << std::endl;
  emscripten_fetch_close(fetch);
}

int main(int argc, char** argv) {
  //auto t1 = std::thread(fetch_emsc);         //┐ swap these two
  auto t1 = std::thread(fetch_xhr);            //┘
  t1.join();                                   //<--hang here
  std::cout << "threads joined" << std::endl;

  return EXIT_SUCCESS;
}

Compile like: emcc test.cpp -s WASM=0 -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=4 -s FETCH=1 -std=c++11 -o test.html

Execution seems to be stuck in the following area:

_emscripten_current_thread_process_queued_calls
_emscripten_main_thread_process_queued_calls
asm._emscripten_main_thread_process_queued_calls
_emscripten_futex_wait
_pthread_join
__ZNSt3__26thread4joinEv
_main

This seems a bit odd to me, as I would have thought you could perform an xhr from a non-main thread without any interaction from the main thread (unless you need to write to IndexedDB).

Any thoughts? Basically my end goal is to have a thread pause execution until a remote resource is downloaded. Unfortunately I can't use callbacks/promises here without a major rewrite of some old C++.

[kripken]

cc @juj

[juj]

It is possible that this can deadlock. The reason for this is that there is no guarantee from web specification viewpoint that a synchronous XHR (xhr.send(); in a worker) would not need help from main browser thread to perform the XHR request.

But the main thread is synchronously busy waiting for the thread to join, so it will never yield back to browser code to kick off the XHR (or whatever it needs, e.g. filesystem access, or socket access, or so on)

To remedy, try using the linker flag -s PROXY_TO_PTHREAD=1, that will keep the main browser thread free. Does that resolve the issue? In that mode, you can drop the -s PTHREAD_POOL_SIZE directive.

I would have thought you could perform an xhr from a non-main thread without any interaction from the main thread (unless you need to write to IndexedDB).

This is a logical assumption, one that I also held for a long time with respect to new Worker() creation, which eventually led to requiring adding that PTHREAD_POOL_SIZE option. Almost all web specifications predate Atomics/SharedArrayBuffer, and they do not specify any semantics with respect to "can this lock on the main thread". Even console.log() done in a pthread might require taking a lock in main browser thread code, which is why there exists code to proxy console.log() from workers to main thread via postMessage() to avoid a deadlock. (In Firefox console.log() used to require taking a lock on main thread, but it was since "fixed", even when it is not a spec requirement)

[VirtualTim]

Swapping PTHREAD_POOL_SIZE with PROXY_TO_PTHREAD=1 makes fetch_xhr succeed, but fetch_emsc fail.

fetch_xhr prints:

10:25:36.709 Preallocating 1 workers for a pthread spawn pool.
10:25:37.300 Preallocating 1 workers for a pthread spawn pool.
10:25:37.935 state:4, status:200
10:25:37.951 threads joined
10:25:37.963 ExitStatus: Program terminated with exit(0)

The png downloads, and it looks to me like the thread waits properly before joining.
fetch_emsc prints:

10:28:50.435 Preallocating 1 workers for a pthread spawn pool.
10:28:50.523 fetch: indexedDB.open(dbname="emscripten_filesystem", dbversion="1");
10:28:50.528 fetch: IndexedDB successfully opened.
10:28:50.811 Preallocating 1 workers for a pthread spawn pool.
10:28:51.106 status: 0

The png does not download, and the program does not seem to ever exit. But at least the main thread isn't hung. I'm not really sure what's going on here.

Thanks for your explanation by the way. Coming from a C++ background there are a lot of assumptions that I'm (and the library I'm trying to port) are making which are not necessarily true in Javascript. I'll do some testing with PROXY_TO_PTHREAD + XMLHttpRequest and more complex examples and see if that's a reasonable solution. I may not get around it it today, but I'll update the issue when I do.

[VirtualTim]

So quick update, I can't get my program to run using PROXY_TO_PTHREAD=1, as my main method is calling emscripten_set_canvas_element_size, and that's throwing ReferenceError: document is not defined.

There's a couple of bugs in the html5 library when run from worker. Here we're using if (canvas) to check if var canvas = __findCanvasEventTarget(target); succeeds. However __findCanvasEventTarget will throw if not run on the main thread.

Fixing that (locally) the program still exits prematurely, even though -s NO_EXIT_RUNTIME=1 is used.

I'll submit a PR tomorrow for library_html5, but I'm not sure yet what's going on the the exiting runtime.
Edit: PR is up: #8185.

[VirtualTim]

So using the changes from the above PR, and adding emscripten_exit_with_live_runtime(); to the end of my main causes my code to fail inside:

void CopyToCanvas(uint32_t* ptr, int w0, int h0, int w, int h){
  EM_ASM_({
    var data = Module.HEAPU8.slice($0, $0 + $3 * $4 * 4);
    var context = Module['canvas'].getContext('2d', {alpha: false});
    var imageData = context.getImageData($1, $2, $3, $4);
    imageData.data.set(data);
    context.putImageData(imageData, $1, $2);
  }, ptr, w0, h0, w, h);
}

because Module['canvas'] is not defined. I'm guessing that this call should be proxied to the main thread, but I can't see how to do that. If I comment that out it appears to work (but obviously nothing gets displayed). Any better ideas on how to stamp an rgba array onto a canvas from a web worker?

EDIT: easy fix for the above, swap EM_ASM_ with MAIN_THREAD_EM_ASM.

[VirtualTim]

So I've basically got things working on my end. Coming from a c++ background, the code in the initial bug report still looks like it should work, but I understand why it doesn't. But since I've managed to resolve things feel free to close the issue.

---

In case anyone else runs into the same issue here's how I got around the problem:
The Issue:
t1.join(); when called from the main thread blocks. XMLHttpRequests are required to run on the main thread. This appears to be transparently proxied by the browser. So the XMLHttpRequest and the join() end up in a deadlock.

How to Fix:
Don't call join() from the main thread. I'm pretty sure that this should process the queued calls to main, but it's currently not happening (see #7388), so it's going to fail.
What I did was have a click callback which spawns then detaches a thread, then that thread can spawn other threads, and wait on them. Basically if you're using thread.join() on the main thread you need to re-work things so that you can use thread.detach().
If your main has to be synchronous, have your main spawn/detach a thread which performs all your synchronous operations.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.