== v0.10.0
- default to two subprocesses if CPU core count cannot be guessed.
Which is change from the old default of five.
- add XPool#resize
Resize the pool at runtime.
If subprocesses are removed from the pool a graceful shutdown is performed on
each subprocess that is removed (unlike resize!, which forces a shutdown).
- add XPool#expand
Expand the pool with X subprocesses, where X is the argument to expand(…).
- add XPool#shrink
Shrink the pool by X subprocesses, where X is the argument to shrink(…).
A graceful shutdown is performed on any subprocesses removed from the pool.
- add XPool#shrink!
Shrink the pool by X subprocesses, where X is the argument to shrink!(…)
A forceful shutdown is performed on any subprocesses removed from the pool.
- XPool#resize! now accepts a Fixnum, not a Range.
If you want to resize the pool to two subprocesses, the API is now:
pool.resize!(2)
- XPool#failed_processes persists after a shutdown
If a process in the pool has failed and the pool is subsequently shutdown the
failed process will remain in XPool#failed_processes. When a failed process
is restarted the pool is repopulated with an active subprocess and can be
used to schedule work again.
- optimize XPool#resize!
A few optimizations:
* when new_size == current_size, there's no resize. nothing happens. it's
a no-op.
* when new_size > current_size, only X new subprocesses are spawned, where X is
the difference between "new_size - current_size".
* when new_size < current_size, all subprocesses indexed after new_size are
shutdown and removed from the pool. no new subprocesses are spawned.
This new behavior reuses subprocesses that are already active in the pool when
it can, where as before we always spawned new subprocesses, no matter what the
case.
== v0.9.0.1,v0.9.0.2
- doc improvements
Revised & improved the README & API documentation.
== v0.9.0
- upgrade to ichannel v5.1.1
Which in turn fixes a performance bug in XPool#schedule. With ichannel v5.0.1
the suite runs in 23~ seconds, but with v5.1.1 we run the suite in 3~ seconds.
I don't think the performance hit was that bad in earlier versions, but given
the right set of circumstances I'm sure it would be an issue.
- add XPool::Process#idle?
Returns true when the subprocess is considered idle. "idle" means the
subprocess is not executing a unit of work.
- conserve CPU consumption by sleeping for a short period of time.
By sleeping for a short period of time we avoid pegging the CPU at
80-100% when a subprocess is idle.
- add XPool::Process#backtrace
Returns the backtrace of the exception that caused a subprocess to fail. Returns
nil whenever the subprocess is not in a failed state.
- add XPool::Process#failed?
Returns true when a unit of work does not handle an exception, which causes
the subprocess it is running in to exit. A failed subprocess can be restarted
through Process#restart.
- add XPool::Process#restart
Restarts a subprocess by gracefully shutting down and respawning a new subprocess.
- add XPool#dry?
Returns true when all subprocesses in the pool are busy.
- XPool::Process#schedule raises when the subprocess is dead
Incase the subprocess has been shutdown a call to XPool::Process#schedule will
raise a RuntimeError.
- XPool#schedule raises when the pool has no active subprocesses
Incase the pool has been shutdown a call to XPool#schedule will raise a
RuntimeError.
- add XPool::Process#frequency
Returns the number of times a subprocess has been asked to schedule work.
- XPool#schedule schedules work on the least busy subprocess
The subprocess picked to run a unit of work is the one who is least busy.
"least busy" means it has been asked to schedule the least amount of
work.
- XPool#schedule returns a XPool::Process object.
The subprocess that has been picked to run your unit of work is returned
by schedule in case you want to interact with the subprocess later on.
- Add XPool#broadcast
The broadcast method can distribute one unit of work across all
subprocesses in the pool.
- Add XPool::Process#busy?
Returns true when the subprocess is executing a unit of work.
== v0.3.0
* Add XPool#size.
It returns the number of alive subprocesses in the pool.
== v0.2.0
* Minor README & API documentation improvements.
* Change the default number of subprocesses to spawn in a pool from 10 to 5.
- default to two subprocesses if CPU core count cannot be guessed.
Which is change from the old default of five.
- add XPool#resize
Resize the pool at runtime.
If subprocesses are removed from the pool a graceful shutdown is performed on
each subprocess that is removed (unlike resize!, which forces a shutdown).
- add XPool#expand
Expand the pool with X subprocesses, where X is the argument to expand(…).
- add XPool#shrink
Shrink the pool by X subprocesses, where X is the argument to shrink(…).
A graceful shutdown is performed on any subprocesses removed from the pool.
- add XPool#shrink!
Shrink the pool by X subprocesses, where X is the argument to shrink!(…)
A forceful shutdown is performed on any subprocesses removed from the pool.
- XPool#resize! now accepts a Fixnum, not a Range.
If you want to resize the pool to two subprocesses, the API is now:
pool.resize!(2)
- XPool#failed_processes persists after a shutdown
If a process in the pool has failed and the pool is subsequently shutdown the
failed process will remain in XPool#failed_processes. When a failed process
is restarted the pool is repopulated with an active subprocess and can be
used to schedule work again.
- optimize XPool#resize!
A few optimizations:
* when new_size == current_size, there's no resize. nothing happens. it's
a no-op.
* when new_size > current_size, only X new subprocesses are spawned, where X is
the difference between "new_size - current_size".
* when new_size < current_size, all subprocesses indexed after new_size are
shutdown and removed from the pool. no new subprocesses are spawned.
This new behavior reuses subprocesses that are already active in the pool when
it can, where as before we always spawned new subprocesses, no matter what the
case.
== v0.9.0.1,v0.9.0.2
- doc improvements
Revised & improved the README & API documentation.
== v0.9.0
- upgrade to ichannel v5.1.1
Which in turn fixes a performance bug in XPool#schedule. With ichannel v5.0.1
the suite runs in 23~ seconds, but with v5.1.1 we run the suite in 3~ seconds.
I don't think the performance hit was that bad in earlier versions, but given
the right set of circumstances I'm sure it would be an issue.
- add XPool::Process#idle?
Returns true when the subprocess is considered idle. "idle" means the
subprocess is not executing a unit of work.
- conserve CPU consumption by sleeping for a short period of time.
By sleeping for a short period of time we avoid pegging the CPU at
80-100% when a subprocess is idle.
- add XPool::Process#backtrace
Returns the backtrace of the exception that caused a subprocess to fail. Returns
nil whenever the subprocess is not in a failed state.
- add XPool::Process#failed?
Returns true when a unit of work does not handle an exception, which causes
the subprocess it is running in to exit. A failed subprocess can be restarted
through Process#restart.
- add XPool::Process#restart
Restarts a subprocess by gracefully shutting down and respawning a new subprocess.
- add XPool#dry?
Returns true when all subprocesses in the pool are busy.
- XPool::Process#schedule raises when the subprocess is dead
Incase the subprocess has been shutdown a call to XPool::Process#schedule will
raise a RuntimeError.
- XPool#schedule raises when the pool has no active subprocesses
Incase the pool has been shutdown a call to XPool#schedule will raise a
RuntimeError.
- add XPool::Process#frequency
Returns the number of times a subprocess has been asked to schedule work.
- XPool#schedule schedules work on the least busy subprocess
The subprocess picked to run a unit of work is the one who is least busy.
"least busy" means it has been asked to schedule the least amount of
work.
- XPool#schedule returns a XPool::Process object.
The subprocess that has been picked to run your unit of work is returned
by schedule in case you want to interact with the subprocess later on.
- Add XPool#broadcast
The broadcast method can distribute one unit of work across all
subprocesses in the pool.
- Add XPool::Process#busy?
Returns true when the subprocess is executing a unit of work.
== v0.3.0
* Add XPool#size.
It returns the number of alive subprocesses in the pool.
== v0.2.0
* Minor README & API documentation improvements.
* Change the default number of subprocesses to spawn in a pool from 10 to 5.