-
Notifications
You must be signed in to change notification settings - Fork 246
Find PendingIterator in Transaction Pool #218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -611,20 +611,26 @@ impl<'a, T, R, S, L> Iterator for PendingIterator<'a, T, R, S, L> where | |
| self.best_transactions.take(&best).expect("Just taken from iterator; qed") | ||
| }; | ||
|
|
||
| match self.ready.is_ready(&best.transaction) { | ||
| Readiness::Ready => { | ||
| // retrieve next one from that sender. | ||
| let tx_state = self.ready.is_ready(&best.transaction); | ||
| // Add the next best sender's transaction when applicable | ||
| match tx_state { | ||
| Readiness::Ready | Readiness::Stale => { | ||
| // retrieve next one from the same sender. | ||
| let next = self.pool.transactions | ||
| .get(best.transaction.sender()) | ||
| .and_then(|s| s.find_next(&best.transaction, &self.pool.scoring)); | ||
| if let Some((score, tx)) = next { | ||
| self.best_transactions.insert(ScoreWithRef::new(score, tx)); | ||
| } | ||
|
|
||
| return Some(best.transaction.transaction) | ||
| }, | ||
| state => trace!("[{:?}] Ignoring {:?} transaction.", best.transaction.hash(), state), | ||
| _ => (), | ||
| } | ||
|
|
||
| if tx_state == Readiness::Ready { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've actually meant to put the if inside previous match and leave the trace in Just got an idea that for readability we could also change both this
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought it would be clearer to have one match when we need to find the next transactions, and another one when we need to return the transaction, but I'm open to anything :)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My reasoning was that it's easier to see everything that happens in particular case(ses) in a single block, cause now you fall-through and need to analyze multiple blocks to think about what happens. But as I said, I'm not strong on this either. |
||
| return Some(best.transaction.transaction) | ||
| } | ||
|
|
||
| trace!("[{:?}] Ignoring {:?} transaction.", best.transaction.hash(), tx_state); | ||
| } | ||
|
|
||
| None | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.