On Mon, Feb 4, 2019 at 2:10 PM <[email protected]> wrote: > Thanks for the explanation, I think I understand where the problem is now. > It seems it happens due to use of emscripten::val in our queuing logic. The > first worker passes requests in a queue which are processed by other > threads and the requests have access to an emscripten::val. When the > emscripten::val is accessed from those threads the error is thrown in the > browser. :( I will have to investigate the best way to work around this > limitation. > > I can also see these limitations making things more difficult memory-wise > as the single-threaded version of the application makes good use of > external file objects and external buffers to keep the heap memory usage > down and I assume for the same reasons we can't easily share these between > threads? >
I believe filesystem access should be proxied to the main thread where necessary already, but I'm less familiar with the filesystem options as I don't use that in my projects. In general, anything in linear memory is golden for pthread access -- but anything that needs the main thread's (in this case, first worker's) JS context needs to either have calls be proxied to that thread, or needs to be retooled. Depending on how much interaction with the JS objects you need (reading/writing some data once vs continual accesses or bidirectional function calls) this might be easy or hard. :) It may also be possible to transfer certain kinds of objects to a thread with postMessage and then interact with them over embind, but that could be .... a bit fiddly. And wouldn't allow for things with function calls etc. -- brion -- 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.
