Merged
Conversation
Member
|
ACK on the code changes, but one nitpick: can you separate the git commit summary (the first line) and the rest? Some git tools assume everything up to the first empty line is the summary. |
o Remove unused Leave and GetLock functions
o Make Enter and TryEnter private.
o Simplify Enter and TryEnter.
boost::unique_lock doesn't really know whether the
mutex it wraps is locked or not when the defer_lock
option is used.
The boost::recursive_mutex does not expose this
information, so unique_lock only infers this
knowledge. When taking the lock is defered, it
(randomly) assumes that the lock is not taken.
boost::unique_lock has the following definition:
unique_lock(Mutex& m_,defer_lock_t):
m(&m_),is_locked(false)
{}
bool owns_lock() const
{
return is_locked;
}
Thus it is a mistake to check owns_lock() in Enter
and TryEnter - they will always return false.
Contributor
Author
|
Done. |
Member
|
ACK |
|
Compiles just fine on Windows and causes no obvious problems, can't really comment on the changes though. |
|
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/bfc96207998c284e2cb6eb99c99b755a161e723d for binaries and test log. |
laudney
pushed a commit
to reddcoin-project/reddcoin-3.10
that referenced
this pull request
Mar 19, 2014
…xlock Simplify CMutexLock
SmarterHomes
pushed a commit
to chaincoin/chaincoin
that referenced
this pull request
Apr 6, 2018
There are no watchdogs and it makes no sense to limit triggers by size (invalid triggers are going to be voted down anyway). 512 bytes should be more than enough for any proposal - the only value we do not check size of is URL and with 512 bytes total limit URL has space for almost 300 bytes.
KolbyML
pushed a commit
to KolbyML/bitcoin
that referenced
this pull request
Dec 5, 2020
… calculation. 75ffadf GUI: Fix shield coins fee calculation. (furszy) Pull request description: With the introduction of the dynamic fee calculation for shielded transaction (bitcoin#1979), the "shield all transparent balance" flow got broken due the different fee requirements. In other words, as we are shielding all the available transparent balance, the dynamic fee requirement needs to be known before hand to be subtracted from the total amount that is going to be shielded (otherwise the wallet has no other utxo to add to the transaction to cover the fee). So.. this PR fixes it calculating and subtracting the fee from the recipient total amount before create the transaction. ACKs for top commit: random-zebra: utACK 75ffadf Fuzzbawls: utACK 75ffadf Tree-SHA512: e3f69e24dd26749f246190c06302f631e571c0312ac93acc5a41de3fb7e30e1cdb9349994254f5a071ae3e1becac825b2c74b1e28a0db1a329678d59b90a88fd
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
o Remove unused Leave and GetLock functions
o Make Enter and TryEnter private.
o Simplify Enter and TryEnter.
boost::unique_lock doesn't really know whether the
mutex it wraps is locked or not when the defer_lock
option is used.
The boost::recursive_mutex does not expose this
information, so unique_lock only infers this
knowledge. When taking the lock is defered, it
(randomly) assumes that the lock is not taken.
boost::unique_lock has the following definition:
Thus it is a mistake to check owns_lock() in Enter
and TryEnter - they will always return false.