I wrote an app to process gcode files in C/C++ compiled using emscripten. File parsing and processing is done in std::threads. Displaying in webgl is done using Threejs on main browser thread.
Now, I need to do offscreen canvas with threejs in a web worker so I can speedup display. The ideal situation is where I could access Wasm from main browser thread and web worker, so I could load the 3d webgl data to send to threejs from the web worker, and fetch statistical data from the main browser thread to display to the user.
If I do send the wasm memory and wasm module to the javascript manually created webworker, I get some stack-pointer exception when calling wasm functions (as it seems emscripten with pthreads initialize a thread stack for every workers). I mean here that a copied, pasted some parts of myapp.worker.js generated by emscripten into a worker file, let's say myapp.threejs.worker.js.
I have these options:
Create a webworker form javascript, and access wasm only from this worker. Main browser thread must then communicate throught the worker to access wasm, affecting performance if some data is hardly transferable
Create a new thread in wasm, create a C api to call javascript and threejs in worker. The problem is, if a spawn a thread from wasm, I can not actually send the offscreen canvas to the web worker through wasm, unless I can communicate directly from javascript to web worker spawned by wasm.
Create a web worker from javascript, but communicate with wasm through main browser thread only. This approch suffers from UI blocking while receiving GL data, as it must pass on the UI thread.
My question is: is there a way to create a web worker from javascript and access wasm from web worker and main thread ? If not, is there a way to spawn a new web worker from wasm thread but post and receive message from javascript in main browser thread without passing through wasm ? Thanks.
Related
Am building a electron app where am running network call in main process and database operations should be done from both main process and render process, as IndexedDB is browser based api we can access dexie directly in renderer process but main process throws exception as below:
"UnhandledPromiseRejectionWarning: MissingAPIError: indexedDB API missing".
I am in need to call an external *.exe compiled in C++
from ASP.NET WEB API 2 using Process (System.Diagnostics)
This executable does some image processing stuff and use lot of memory.
SO my question is if change my API calls to Async. or implement threads will it help, Or it doesn't matter?
Note: All i have is executable so i can not go for a CLI Wrapper.
You can separate the two. Your api is one thing, it needs to be fast, responsive to be able to serve the clients. Your image processing thing is different.
You could implement a queuing system. The api is responsible for adding a new item to this queue and nothing more. You could keep track of what tasks are being run in a separate sql table let's say. Imagine you have a sql table called Tasks. Your api chucks data in there and the status is "Not Running".
Some other app which lives on another machine entirely keeps an eye on this table and takes care of running that executable for each item. When it starts, it changes the status to Running, when it completes it's Done. You do whatever else you need. You could have an api endpoint which takes the ID of the task so your client can keep calling this endpoint to see what the status is. Or you could raise an event when it's done, depending on your application needs.
Bottom line, keep things separate, you gain nothing for blocking the api while a resources heavy task is running. Think what happens if you start that process 5 times, at the same time. You've just killed your api basically.
The app that does the heavy work, could even be located on a separate machine, so it doesn't affect the api at all.
I'm new to electron and I want to make sure I understand the distinction between code that is appropriate for the main process vs the renderer process. The app is essentially a React app hosted inside a single electron page. So, as I understand it, I have one main process and one render process.
If I want to make REST calls as part of the React app (using axios for example), I assume I can do it inside the React code within the renderer process, right? No need to go to the main process for that is there?
I also have to create a socket connection to an outside server. This is not an HTTP REST interface, it's a raw TCP/IP socket. Can this also be done within the renderer process or do I need to go to the main for that?
I tried putting the socket calls using node's net library and it seems to work okay. The very first time I got some kind of connection error but subsequent tries seem to be working. That one error is making me wonder if using net inside the renderer is a good idea though.
I execute core data request not on main thread when my app is called to do background fetch (app state is background), and method freezes forever.
But when I use main thread, it works.
Should I always use main thread for core data when in background mode? Does there is some apple doc about it?
I would like to notify my main application (if it is still running) when the ScheduledAgent has finished its background task.
Is it actually possible? I couldn't figure out how I could reference my App or MainPage
For simply protecting shared data access between main app and background agent using Mutexes have a look at this question. Maybe this already gives you a hint in the right direction.
But if you want to react to events like "the background agent just finished" (in main app) or "the main app starts up" (in background agent) then you might be out of luck. There is no simple direct communication available, let alone direct data access. You could use Sockets or Raw Notifications.
A method based on polling and Mutexes is discussed in this question.