emulate require.resolve about npool

[inh3]

I definitely want to address this. I actually ran into some issues as well which led me to begin updating the require() functionality. I'm actually working on a major update which will include a revamp of the global context for the threads, so that many of the commonly used global objects are available (including __dirname, __filename, and console). Part of this work includes better require() support. You can see the work-in-progress on the "experimental" branch.

I will attempt to satisfy all requirements of the algorithm, but can you provide an example of some use-cases that are breaking?

One extra thing to note, at this time I still do not intend to support core Node.js modules or native C/C++ add-ons from within the threads.

[terinjokes]

I wanted to do some work spread across all the CPUs in my box. I can require node modules via require('./node_modules/xxx/index.js') and this works so long as they don't have dependencies themselves or any relative requires, since the relative requires seem to be resolved relative to the worker.

So, effectively, I have to redo all work developed by most node modules because I can't require them safely in a worker.

If I try, 9 times out of 10 I get a segfault.

[inh3]

Accidentally clicked the close button...

I understand the pain and am addressing the path resolution issues in the current updates to require()

[terinjokes]

Thanks. I got the best performance from this library (compared to children), so glad to see improvements.

[inh3]

Just an update on this issue. Tonight I updated nPool to version 1.1.0. This included the following changes:

• Support for commonly used Node.js global objects
  • require()
    • Supports file-based requiring
    • Paths that start with './' and '../' is relative to file performing require()
  • console.log
  • __filename
  • __dirname

This should help alleviate some of the pain with requiring files within worker modules. Think of this as phase one for emulating the require() functionality. My next focus is to completely replicate it (with the exception of native modules of course). This will be a minor version bump, most likely 1.1.1.

[terinjokes]

I no longer require this functionality. Closing the issue, fill free to reopen if you plan on working on it.