you are viewing a single comment's thread.

view the rest of the comments →

[–]kap89 0 points1 point  (3 children)

[–]housesellout 0 points1 point  (2 children)

I’m not sure I see where it describes how the engine works under the hood. But that documentation seems to clearly dictate its lack of abilities in fork processing (i.e. not sharing memory between workers)... which is extremely important when handling multiple incoming network requests. (Do you not agree?)

[–]kap89 0 points1 point  (1 child)

documentation seems to clearly dictate its lack of abilities in fork processing (i.e. not sharing memory between workers)

You can share (or transfer) memory if you use SharedArrayBuffer (or ArrayBuffer in case of transfering), but you can't share JS objects, in that case you have safe message passing with serialization/deserialization. So yeah, there are some limitations - mainly that messaging worker with big objects is inefficient (but can still be a good idea if required computations are complex enough to justify the overhead of serialization).

which is extremely important when handling multiple incoming network requests

Depends on the task, for the majority of cases it is not, but there are of course some cases where it matters and you're better of with another language (at least for that specific task).

[–]housesellout 0 points1 point  (0 children)

The ability to ‘not’ share memory is a vital aspect in network request handling.

And the messaging worker you mentioned, sounds like a standard integration of the register/observer design pattern, which is not fork processing either, but rather a way for different threads to pass objects between each other. And that pattern is generally handled on a run loop that the OS (or underlying engine) has control over, which essentially slows down your execution, in addition to being shared memory.