| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
anymore, but are abstract.
Added IteratorReader, implementing the reader interface from an iterator. The implementation moved from the TaskIterator to the channel
|
|
|
|
|
|
| |
readers and writers, a ready is not connected to its writer anymore. This changes the refcounting of course, which is why the auto-cleanup for the pool is currently broken.
The benefit of this are faster writes to the channel, reading didn't improve, refcounts should be clearer now
|
|
|
|
| |
channel implementation, one of which is used as base by the Pool Read channel, releasing it of the duty to call these itself. The write channel with callback subclass allows the transformation of the item to be written
|
|
|
|
|
|
| |
makes it easier to constomize
pool: in serial mode, created channels will be serial-only, which brings 15% of performance
|
|
|
|
| |
and it runs faster as well, about 2/3 of the performance we have when being in serial mode
|
|
|
|
| |
task class
|
|
|
|
| |
the wrong spot. The channel is nothing more than an adapter allowing to read multiple items from a thread-safe queue, the queue itself though must be 'closable' for writing, or needs something like a writable flag.
|
|
|
|
|
|
| |
multiple connected pools
Reduced waiting time in tests to make them complete faster
|
|
|
|
| |
related to our channel closed flag, which is the only way not to block forever on read(0) channels which were closed by a thread 'in the meanwhile'
|
|
|
|
| |
while going. Tests will be written soon for verification, its still quite theoretical
|
|
going on. The default implementation uses threads, which ends up being nothing more than async, as they are all locked down by internal and the global interpreter lock
|