worker-farm - npm Package Compare versions

Comparing version 0.0.0 to 0.0.1

lib/farm.js

@@ -179,3 +179,4 @@ const fork = require('./fork')
           if (this.ending === false) return
-          this.ending = callback || true
+          if (callback) this.ending = callback
+          else if (this.ending == null) this.ending = true
           Object.keys(this.children).forEach(function (child) {
@@ -190,4 +191,4 @@ if (!this.children[child]) return
           if (complete && typeof this.ending == 'function') {
+            this.ending()
             this.ending = false
-            this.ending()
           }
@@ -194,0 +195,0 @@ }

package.json

 {
     "name"            : "worker-farm"
-  , "description"     : "Distribute processing tasks to child processes with a simple API, durability & custom concurrency requirements"
-  , "version"         : "0.0.0"
+  , "description"     : "Distribute processing tasks to child processes with an über-simple API and baked-in durability & custom concurrency options."
+  , "version"         : "0.0.1"
   , "homepage"        : "https://github.com/rvagg/node-worker-farm"
@@ -6,0 +6,0 @@ , "authors"         : [

README.md

 # Worker Farm [![Build Status](https://secure.travis-ci.org/rvagg/node-worker-farm.png)](http://travis-ci.org/rvagg/node-worker-farm)
 
-Distribute processing tasks to child processes with an über-simple API and baked-in durability & custom concurrency options.
+Distribute processing tasks to child processes with an über-simple API and baked-in durability & custom concurrency options. *Available in npm as <strong>worker-farm</strong>*.
 
@@ -46,8 +46,19 @@ ## Example
 
-This example is contained in the *[examples/basic](https://github.com/rvagg/node-levelup/tree/master/examples/basic/)* directory.
+This example is contained in the *[examples/basic](https://github.com/rvagg/node-worker-farm/tree/master/examples/basic/)* directory.
 
 ### Example #1: Estimating π using child workers
 
-You will also find a more complex example in *[examples/pi](https://github.com/rvagg/node-levelup/tree/master/examples/pi/)* that estimates the value of **π** by using a Monte Carlo *area-under-the-curve* method and compares the speed of doing it all in-process vs using child workers to complete separate portions.
+You will also find a more complex example in *[examples/pi](https://github.com/rvagg/node-worker-farm/tree/master/examples/pi/)* that estimates the value of **π** by using a Monte Carlo *area-under-the-curve* method and compares the speed of doing it all in-process vs using child workers to complete separate portions.
 
+Running `node examples/pi` will give you something like:
+
+```
+Doing it the slow (single-process) way...
+π ≈ 3.1416269360000006  (0.0000342824102075312 away from actual!)
+took 8341 milliseconds
+Doing it the fast (multi-process) way...
+π ≈ 3.1416233600000036  (0.00003070641021052367 away from actual!)
+took 1985 milliseconds
+```
+
 ## Durability
@@ -57,3 +68,3 @@
 
-## Use-case
+## My use-case
 
@@ -64,2 +75,4 @@ There are other libraries for managing worker processes available but my use-case was fairly specific: I need to make heavy use of the [node-java](https://github.com/nearinfinity/node-java) library to interact with JVM code. Unfortunately, because the JVM garbage collector is so difficult to interact with, it's prone to killing your Node process when the GC kicks under heavy load. For safety I needed a durable way to make calls so that (1) it wouldn't kill my main process and (2) any calls that weren't successful would be resubmitted for processing.
 
+**But**, don't think that Worker Farm is specific to that use-case, it's designed to be very generic and simple to adapt to anything requiring the use of child Node processes.
+
 ## API
@@ -99,10 +112,17 @@
 
-* **`maxCallsPerWorker`** allows you to control the lifespan of your child processes. A positive number will indicate that you only want each child to accept that many calls before it is terminated. This may be useful if you need to control memory leaks or similar in child processes.
+  * **<code>maxCallsPerWorker</code>** allows you to control the lifespan of your child processes. A positive number will indicate that you only want each child to accept that many calls before it is terminated. This may be useful if you need to control memory leaks or similar in child processes.
 
-* **`maxConcurrentWorkers`** will set the number of child processes to maintain concurrently. By default it is set to the number of CPUs available on the current system, but it can be any reasonable number, including `1`.
+  * **<code>maxConcurrentWorkers</code>** will set the number of child processes to maintain concurrently. By default it is set to the number of CPUs available on the current system, but it can be any reasonable number, including `1`.
 
-* **`maxConcurrentCallsPerWorker`** allows you to control the *concurrency* of individual child processes. Calls are placed into a queue and farmed out to child processes according to the number of calls they are allowed to handle concurrently. It is arbitrarily set to 10 by default so that calls are shared relatively evenly across workers, however if your calls predictably take a similar amount of time then you could set it to `-1` and Worker Farm won't queue any calls but spread them evenly across child processes and let them go at it. If your calls aren't I/O bound then it won't matter what value you use here as the individual workers won't be able to execute more than a single call at a time.
+  * **<code>maxConcurrentCallsPerWorker</code>** allows you to control the *concurrency* of individual child processes. Calls are placed into a queue and farmed out to child processes according to the number of calls they are allowed to handle concurrently. It is arbitrarily set to 10 by default so that calls are shared relatively evenly across workers, however if your calls predictably take a similar amount of time then you could set it to `-1` and Worker Farm won't queue any calls but spread them evenly across child processes and let them go at it. If your calls aren't I/O bound then it won't matter what value you use here as the individual workers won't be able to execute more than a single call at a time.
 
+### workerFarm.end(farm)
+
+Child processes stay alive waiting for jobs indefinitely and your farm manager will stay alive managing its workers, so if you need it to stop then you have to do so explicitly. If you send your farm API to `workerFarm.end()` then it'll cleanly end your worker processes. Note though that it's a *soft* ending so it'll wait for child processes to finish what they are working on before asking them to die.
+
+Once you end a farm, it won't handle any more calls, so don't even try!
+
+
 ## Licence
 
 Worker Farm is Copyright (c) 2012 Rod Vagg [@rvagg](https://twitter.com/rvagg) and licenced under the MIT licence. All rights not explicitly granted in the MIT license are reserved. See the included LICENSE file for more details.

tests/index.js

@@ -236,2 +236,18 @@ var tape       = require('tape')
   }
+})
+
+// a callback provided to .end() can and will be called (uses "simple, exports=function test" to create a child)
+tape('simple, end callback', function (t) {
+  t.plan(4)
+
+  var child = workerFarm(childPath)
+  child(0, function (err, pid, rnd) {
+    t.ok(pid > process.pid, 'pid makes sense')
+    t.ok(pid < process.pid + 100, 'pid makes sense')
+    t.ok(rnd > 0 && rnd < 1, 'rnd result makes sense')
+  })
+
+  workerFarm.end(child, function() {
+    t.pass('an .end() callback was successfully called')
+  });
 })

No alert changes

Improved metrics

Total package byte prevSize

30146

increased by6.01%

Lines of code

534

increased by2.69%

Number of lines in readme file

125

increased by19.05%

No dependency changes