Txrdq

Latest version: v0.2.14

Safety actively analyzes 688600 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 2

0.2.14

---------------------------------------

There was a problem when running trial tests with a job handler that raised an
error. This was due to calling job.watch and not ignoring the error it received.
The original problem was reported at http://stackoverflow.com/questions/9728781/testing-a-failing-job-in-resizabledispatchqueue-with-trial
(See also the comment below for version 0.2.13, which almost certainly introduced
this bug due to an incorrect fix.)

Thanks to L. Daniel Burr (ldanielburr) who also ran across this, found the
problem, and fixed it.

0.2.13

------------------------------------

Make sure ResizableDispatchQueue._launchJob always returns a Deferred. I'm
not sure how, but sometimes when there is no waiting Deferred on the job,
it's not ok to return None. Either the job has already finished (it may be
synchronous), or a watiting Deferred has somehow yet to be created (seems
impossible since we make one on a put), or the waiting Deferreds have fired
and the job's list of waiting Deferred is now empty. Long-running jobs were
somehow triggering this (see testPuttingMoreThanWidthOnlyDispatchesWidth in
test/test_rdq.py) and were not being waited for by the cooperator.

0.2.12

------------------------------------

Don't use next() in txrdq/dpq.py as it's new in Python 2.6 and I'd like to
be compatible with earlier versions.

0.2.11

------------------------------------

Updated .bzrignore.

0.2.10

------------------------------------

Fixed a bug wherein an initially non-zero queue would have Deferreds
waiting for a job arg and would start job processing on the next put even
if the width of the queue had been set to zero in the meantime. I.e.,
create a queue of size 3 and shortly afterwards there will be 3 calls to
next() that will each get a Deferred awaiting a job arg. Then set the queue
width to zero. Then do a put() and the job arg is given to one of the
waiting Deferreds and is then incorrectly dispatched (the width is zero).

This bug showed that what goes on can be surprising, and I had to scratch
my head to fix it. That's a sure sign this code has gotten too complex.
The logic of setWidth is hard to follow.

0.2.9

----------------------------------

Added a test.

Page 1 of 2

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.