Segmentation fault when workers exit

[fmmoret]

I get segfaults on node 16 and node 18 when I use these in workers.

I'm on linux gnu x64

---

Replication steps:

Just run node segfault.js with:

segfault.js

var import_worker_threads = require("worker_threads");

if (import_worker_threads.isMainThread) {
  const worker = new import_worker_threads.Worker("./segfault");
} else {
  var import_snappy = require("snappy");
}

If the parent thread has also imported it, it seems to work fine:

segfault.js with parent import:

var import_worker_threads = require("worker_threads");
var import_snappy = require("snappy");

if (import_worker_threads.isMainThread) {
  const worker = new import_worker_threads.Worker("./segfault");
}

[fmmoret]

opened parent issue too: napi-rs/package-template#308

[Brooooooklyn]

It's a known issue upstream: rust-lang/rust#91979

My suggestion is don't use woker_threads with NAPI-RS packages, because the async function exposed in snappy or other NAPI-RS packages could have been possible to take advantage of the multi-cores.

In snappy for example:

Promise.all([
  compress("hello"),
  compress("hello"),
  compress("hello"),
  compress("hello"), 
])

the code below will execute in four threads.

[hanlakewind]

@Brooooooklyn So you mean that compress() and uncompress() functions are already multi-threaded without worker threads? If so I feel like this information should be put in the README

[Brooooooklyn]

So you mean that compress() and uncompress() functions are already multi-threaded without worker threads? If so I feel like this information should be put in the README

@hanlakewind Yes, they are already multi-threaded, I'll update README.

[fmmoret]

Got it. I am just using a pool of worker threads for a job queue and happen to be using snappy for some stuff -- caught me by surprise that my queue would crash if I ever had a job NOT doing snappy compression.

Forcing it to stay loaded by requiring in the parent process works for now