feat(process/scanner): offload scanning to a worker thread

[pendo324]

This is a patch for Vencord/Vesktop#1009, which I can reliably reproduce.

It aims to remove any possibility of stutter on the main thread by offloading process scanning to a worker_thread or Web Worker.

I used the threads.js library, because it (should) automatically handle detecting which type of worker to use depending on where you're running (worker_threads for node, Web Worker for a browser).

I've only tried this on Vesktop (electron/node) and it works well (although, I have to include a patch so that the ESBuild bundler that they use can load the worker script properly — I don't think there's a good alternative solution for this other than maybe adding a build step to this package).

The patches/threads+1.7.0.patch file is not strictly necessary, and only helps with typings, since that project is not exporting them properly.

[CanadaHonk]

Thanks for the patch! The server only runs on Node so you can just use node:worker_threads. Honestly, I think this is better done on Vesktop's side just running all of arrpc in another thread but let me know what you think.

[pendo324]

Thanks for the patch! The server only runs on Node so you can just use node:worker_threads.

Makes sense.

Honestly, I think this is better done on Vesktop's side just running all of arrpc in another thread but let me know what you think.

I think it's probably technically possible to implement in Vesktop, but the arrpc server object emits events, some of which (invite) have callbacks, making it slightly complicated.

By putting the entire arrpc server in a web_worker, you can't pass the callback to the main Vesktop thread to handle. I think I should be able to just keep track of the invite callbacks in the worker thread, and then send a message back to the worker thread to handle them appropriately.

[CanadaHonk]

I'm open to implementing it in arRPC, just wanted some clarifications on why it is needed here instead of in users. That makes sense to me, I didn't consider how annoying serialization is with worker_threads :(. Interested in doing it fully (ie own serialization) here but not sure if it will be soon, apologies and thanks.

[pendo324]

I'm open to implementing it in arRPC, just wanted some clarifications on why it is needed here instead of in users. That makes sense to me, I didn't consider how annoying serialization is with worker_threads :(. Interested in doing it fully (ie own serialization) here but not sure if it will be soon, apologies and thanks.

No worries. Honestly, its going to be annoying regardless of where it's done because of Vesktop's bundling anyway

[pendo324]

I think to do it properly in arRPC, it might also be good to detect if the worker_threads module is available before trying to use it, and then have a fallback? Maybe over-engineered though. Depends if you want it to work on other runtimes (deno, bun, etc)