@dmop/puru 0.1.0 → 0.1.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +14 -14
  2. package/package.json +2 -2
package/README.md CHANGED
@@ -1,27 +1,27 @@
1
1
  # puru (プール)
2
2
 
3
- Goroutine-style concurrency for JavaScript with an **M:N scheduler** multiplexes thousands of tasks onto a small pool of OS threads, just like Go.
3
+ A thread pool with Go-style concurrency primitives for JavaScript spawn tasks off the main thread with channels, WaitGroup, select, and more. No worker files, no boilerplate.
4
4
 
5
- Works on **Node.js** and **Bun**. No separate worker files, no manual message passing.
5
+ Works on **Node.js** and **Bun**.
6
6
 
7
7
  *puru (プール) means "pool" in Japanese.*
8
8
 
9
9
  ## Install
10
10
 
11
11
  ```bash
12
- npm install puru
12
+ npm install @dmop/puru
13
13
  ```
14
14
 
15
15
  ## Quick Start
16
16
 
17
17
  ```typescript
18
- import { spawn, chan, WaitGroup, select, after } from 'puru'
18
+ import { spawn, chan, WaitGroup, select, after } from '@dmop/puru'
19
19
 
20
20
  // CPU work — runs in a dedicated worker thread
21
21
  const { result } = spawn(() => fibonacci(40))
22
22
  console.log(await result)
23
23
 
24
- // I/O work — many tasks share worker threads (M:N scheduling)
24
+ // I/O work — many tasks share worker threads
25
25
  const wg = new WaitGroup()
26
26
  for (const url of urls) {
27
27
  wg.spawn(() => fetch(url).then(r => r.json()), { concurrent: true })
@@ -31,10 +31,10 @@ const results = await wg.wait()
31
31
 
32
32
  ## How It Works
33
33
 
34
- puru uses an **M:N scheduler** — M tasks are multiplexed onto N OS threads:
34
+ puru manages a **thread pool** — tasks are dispatched onto a fixed set of worker threads:
35
35
 
36
36
  ```text
37
- puru scheduler
37
+ puru thread pool
38
38
  ┌──────────────────────────────┐
39
39
  │ │
40
40
  │ Task 1 ─┐ │
@@ -58,7 +58,7 @@ puru uses an **M:N scheduler** — M tasks are multiplexed onto N OS threads:
58
58
  | **Exclusive** (default) | `spawn(fn)` | CPU-bound work | 1 task per thread, full core usage |
59
59
  | **Concurrent** | `spawn(fn, { concurrent: true })` | I/O-bound / async work | Many tasks share a thread's event loop |
60
60
 
61
- This is the same model Go uses: goroutines (M) are scheduled onto OS threads (N). CPU-bound work gets a dedicated thread. I/O-bound work shares threads efficiently.
61
+ CPU-bound work gets a dedicated thread. I/O-bound work shares threads efficiently. The API is inspired by Go's concurrency primitives (channels, WaitGroup, select), but the underlying mechanism is a thread pool — not a green thread scheduler.
62
62
 
63
63
  ## Why puru
64
64
 
@@ -112,7 +112,7 @@ const results = await Promise.all(items.map(item => pool.run(item)))
112
112
  **puru** — one file, 4 lines:
113
113
 
114
114
  ```typescript
115
- import { WaitGroup } from 'puru'
115
+ import { WaitGroup } from '@dmop/puru'
116
116
  const wg = new WaitGroup()
117
117
  for (const item of items) wg.spawn(() => heavyWork(item))
118
118
  const results = await wg.wait()
@@ -122,7 +122,7 @@ const results = await wg.wait()
122
122
  | --- | --- | --- | --- | --- |
123
123
  | Separate worker file | Required | Required | Required | **Not needed** |
124
124
  | Inline functions | No | No | No | **Yes** |
125
- | M:N scheduler | No | No | No | **Yes** |
125
+ | Managed thread pool | No | No | No | **Yes** |
126
126
  | Concurrent mode (I/O) | No | No | No | **Yes** |
127
127
  | Channels (cross-thread) | No | No | No | **Yes** |
128
128
  | Cancellation | No | No | No | **Yes** |
@@ -188,7 +188,7 @@ for await (const value of ch) {
188
188
  }
189
189
  ```
190
190
 
191
- **Channels in workers** — pass channels to `spawn()` and use them from worker threads, just like Go:
191
+ **Channels in workers** — pass channels to `spawn()` and use them across worker threads:
192
192
 
193
193
  ```typescript
194
194
  const ch = chan<number>(10)
@@ -375,7 +375,7 @@ npm run bench:bun # all benchmarks (Bun)
375
375
  | Main-thread channels only | 174 ms | 1.0x |
376
376
  | **puru fan-out (4 workers)** | **51 ms** | **3.4x faster** |
377
377
 
378
- ### M:N Concurrent Async (Node.js)
378
+ ### Concurrent Async (Node.js)
379
379
 
380
380
  100 async tasks with simulated I/O + CPU:
381
381
 
@@ -383,7 +383,7 @@ npm run bench:bun # all benchmarks (Bun)
383
383
  | --- | --: | --: |
384
384
  | Sequential | 1,140 ms | baseline |
385
385
  | Promise.all (main thread) | 20 ms | 58x faster |
386
- | **puru concurrent (M:N)** | **16 ms** | **73x faster** |
386
+ | **puru concurrent** | **16 ms** | **73x faster** |
387
387
 
388
388
  Both Promise.all and puru concurrent are fast — but puru runs everything **off the main thread**, keeping your server responsive under load.
389
389
 
@@ -401,7 +401,7 @@ Both Promise.all and puru concurrent are fast — but puru runs everything **off
401
401
  ## Testing
402
402
 
403
403
  ```typescript
404
- import { configure } from 'puru'
404
+ import { configure } from '@dmop/puru'
405
405
  configure({ adapter: 'inline' }) // runs tasks in main thread, no real workers
406
406
  ```
407
407
 
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@dmop/puru",
3
- "version": "0.1.0",
4
- "description": "puru (プール) — Goroutine-style concurrency for JavaScript",
3
+ "version": "0.1.2",
4
+ "description": "puru (プール) — A thread pool with Go-style concurrency primitives for JavaScript",
5
5
  "type": "module",
6
6
  "main": "./dist/index.cjs",
7
7
  "module": "./dist/index.js",