bevry-archive / readdir-cluster Goto Github PK

If so, will need to do a listener and ignore on the children. Or have a way of aborting.

Right now we send each task for the worker individually, this may incur a communication cost, perhaps we can batch the tasks or queue the tasks so that instead of sending each task to the worker individually, we send a batch of 10 at a time, or however many we have queued up while the worker was running, this may reduce communication cost and increase performance at the cost of additional complexity.

I have a use case where I'd like the MD5 hashes of each file. I was about to request that, but then I realised other use cases might want different types of hashes, and other use cases might need something else entirely.

Is it possible to make this run an alternative function in the worker, provided by the consumer of this project (instead of hard coded in this project)?

Is this something you'd accept a PR for?

Using node -e "require('readdir-cluster')(process.cwd(), console.log, console.log)" will fail as the node eval will mean readdir-cluster does not run in the master process, so cluster.setupMaster does not exist. In such circumstances, which we cannot control, we should fallback gracefully, either to spawn #3 or a normal readdir.

http://npmjs.com/package/fdir
https://github.com/thecodrr/fdir

if it is faster, then move https://github.com/bevry/scandirectory over to it, and archive this project

Dependabot encountered the following error when parsing your .dependabot/config.yml:

The property '#/update_configs/0/automerged_updates/0/match/update_type' value "security" did not match one of the following values: all, security:patch, semver:patch, semver:minor, in_range

Please update the config file to conform with Dependabot's specification using our docs and online validator.

@jokeyrhyme: You may not necessarily need to use the cluster module, as you don't need port-level load-balancing for this (as you don't even open ports). I wonder if just using the childProcess built-in instead would be faster?

This is a good point. PR and performance comparison welcome.