Why doesn't `dlopen()` see preloaded files when called from a worker?

[debevv]

I'm trying to dlopen() a bunch of dynamic libraries from a worker (pthread) that I previously packaged with --preload-file. I can confirm they are in the filesystem because I can open(), fopen() etc. them both from the worker and the main thread. dlopen() fails with an error about the .so file not starting with the correct magic number. This is because it can't find the file and falls back to GETting via http:// (or at least this is my explanation of what is happening).

Actually, I know the answer to the question in the title. I followed dlopen() with a debugger and discovered that its filesystem operations are not proxied to the main thread. It is directly using the worker's FS js object which is not the same used by the main thread, apparently the only one that can "see" preloaded files. This is strange because any other filesystem operation from workers is proxied instead.

So why is it that? Is it because of a technical limitation or it can be changed to behave like a normal open()? I'd like to be able to load libraries from the MEMFS because it's much more easy and consistent than having the server provide all the files one by one.

[debevv]

Bump? Did I miss something? Was my question not clear enough?

[sbc100]

I think you have just run into path that we have yet to implement / test. Dynamic linking and threading is still experimental (you should have seen a linker warning about this) so this is not entirely unexpected.

As you have noted, I imagine the solution here would involve proxying the FS operation back to the main thread.

[debevv]

Thank you for the PR!