Age | Commit message (Collapse) | Author |
|
|
|
|
|
"ours" merge to avoid version bump.
|
|
|
|
"Ours merge" to avoid version bump.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The sha3 module should still work. Fixes bug 23071; bugfix on
0.3.1.1-alpha.
|
|
|
|
This is CID 1415726.
|
|
|
|
Fixes bug 23053; CID 1415725.
|
|
|
|
|
|
|
|
|
|
Now that half the threads are permissive and half are strict, we
need to make sure we have at least two threads, so that we'll
have at least one of each kind.
|
|
Fixes bug 22883.
|
|
These comments said that each thread had a separate queue, but we
haven't been using that design for some while.
|
|
Instead of choosing a lower-priority job with a 1/37 chance, have
the chance be 1/37 for half the threads, and 1/2147483647 for the
other half. This way if there are very slow jobs of low priority,
they shouldn't be able to grab all the threads when there is better
work to do.
|
|
Each piece of queued work now has an associated priority value; each
priority goes on a separate queue.
With probability (N-1)/N, the workers will take work from the highest
priority nonempty queue. Otherwise, they'll look for work in a
queue of lower priority. This behavior is meant to prevent
starvation for lower-priority tasks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|