Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node WorkerChannel native addon #1394

Draft
wants to merge 82 commits into
base: v3
Choose a base branch
from
Draft

Node WorkerChannel native addon #1394

wants to merge 82 commits into from

Conversation

jmillan
Copy link
Member

@jmillan jmillan commented May 9, 2024

Substitute spawning a process with mediasoup for running mediasoup in a thread created by this addon.

The communication is now done via message passing rather than using unixsocket, avoiding the kernel networking stack for each and every message passed from Node to C++ and viceversa.

Performance gains are enhanced by approximately 8 times. Tested by sending a request from Node to C++ and waiting for the response N times in a loop.

Caveats:

  • Since we don't use a separate process, a crash in mediasoup would crash Node, meaning it must be handled by node process signal handling.
    • At the same time, the coredumps will be named something-node-something
    • In order to debug coredumps the worker-channel.node binary can be used along with the coredump file and gdb/lldb

TODO:

  • Document removed 'died' and 'subprocessclose' Worker.ts events.
  • Document removed 'died()' and 'subprocessClosed()' Worker.ts methods.
  • Missing all the prebuilt binary upload/download stuff.

jmillan added 2 commits May 9, 2024 18:07
Substitute spawning a process with mediasoup for running mediasoup in a
thread created by this addon.

The communication is now done via message passing rather than using
unixsocket, avoiding the kernel networking stack for each and every
message passed from Node to C++ and viceversa.

Performance gains are enhanced by approximately 8 times. Tested by
sending a request from Node to C++ and waiting for the response N times
in a loop.
.gitignore Outdated Show resolved Hide resolved
@ibc
Copy link
Member

ibc commented May 9, 2024

.prettierignore and .eslintignore should include /node/workerChannel/lib.

node/src/Worker.ts Show resolved Hide resolved
node/src/Worker.ts Show resolved Hide resolved
node/src/Worker.ts Show resolved Hide resolved
npm-scripts.mjs Outdated Show resolved Hide resolved
npm-scripts.mjs Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
@ibc
Copy link
Member

ibc commented May 10, 2024

Please merge v3 and check prettier and eslint path arrays in npm-scripts.mjs

@jmillan jmillan changed the title WIP: Node WorkerChannel native addon Node WorkerChannel native addon Jun 19, 2024
@jmillan
Copy link
Member Author

jmillan commented Oct 15, 2024

Update:

This PR is almost ready to be shipped if we want to.

The are two main concerns already defined in the PR description:

  • Since we don't use a separate process for the application and the worker, a crash in mediasoup would crash Node, meaning it must be handled by node process signal handling. This is true for Rust too.
    • The coredumps will be named something-node-something
    • In order to debug coredumps the worker-channel.node binary can be used along with the coredump file and gdb/lldb
  • Since the worker is now used in multi-thread fashion, the very same concerns apply to Node as to Rust, such us Multi-thread bug when using usrsctp in N Worker threads in Rust #1352

Having said this, do we still want to go in this direction?. As indicated in the description:

Performance gains are enhanced by approximately 8 times. Tested by sending a request from Node to C++ and waiting for the response N times in a loop.

But of course it comes with the mentioned caveats too.

What do you think @ibc, @nazar-pc?

@nazar-pc
Copy link
Collaborator

If there use cases where the performance gap is that large, I think it is worth it. The proper solution to crashes is largely to write code that doesn't crash rather than running it in a separate process.

@ibc
Copy link
Member

ibc commented Oct 15, 2024

I think that keeping the current design just to keep the "benefit" of not crashing the node process if the worker fails is not a good argument so I am ok but:

How does this change affect prebuilt worker binaries? Now they should not be "binaries" but "libraries" so more changes are needed specially in the naming of those assets and the function in npm-script that fetches them.

@jmillan
Copy link
Member Author

jmillan commented Oct 15, 2024

How does this change affect prebuilt worker binaries? Now they should not be "binaries" but "libraries" so more changes are needed specially in the naming of those assets and the function in npm-script that fetches them.

Yes, there is a TODO for this.

👍,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants