EventProcessor needs to handle Ticks between Event batches #216
Assignees
Comments
garious
added a commit
to garious/solana
that referenced
this issue
May 14, 2018
No longer intercept entries to register_entry_id(). Intead, register the ID in the Write stage. EventProcessor is now just being used as a place to store data. Fixes solana-labs#216
aeyakovenko
referenced
this issue
in aeyakovenko/solana
May 14, 2018
No longer intercept entries to register_entry_id(). Intead, register the ID in the Write stage. EventProcessor is now just being used as a place to store data. Fixes #216
vkomenda
pushed a commit
to vkomenda/solana
that referenced
this issue
Aug 29, 2021
…abs#216) Bumps [@babel/runtime](https://github.com/babel/babel/tree/HEAD/packages/babel-runtime) from 7.11.0 to 7.11.1. - [Release notes](https://github.com/babel/babel/releases) - [Changelog](https://github.com/babel/babel/blob/main/CHANGELOG.md) - [Commits](https://github.com/babel/babel/commits/v7.11.1/packages/babel-runtime) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
steviez
added a commit
to steviez/solana
that referenced
this issue
Mar 27, 2024
…a-labs#216) Previously, entry verification had a dedicated threadpool used to verify PoH hashes as well as some basic transaction verification via Bank::verify_transaction(). It should also be noted that the entry verification code provides logic to offload to a GPU if one is present. Regardless of whether a GPU is present or not, some of the verification must be done on a CPU. Moreso, the CPU verification of entries and transaction execution are serial operations; entry verification finishes first before moving onto transaction execution. So, tx execution and entry verification are not competing for CPU cycles at the same time and can use the same pool. One exception to the above statement is that if someone is using the feature to replay forks in parallel, then hypothetically, different forks may end up competing for the same resources at the same time. However, that is already true given that we had pools that were shared between replay of multiple forks. So, this change doesn't really change much for that case, but will reduce overhead in the single fork case which is the vast majority of the time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Historian is pushing Ticks to its Entry sender every X milliseconds. Event processor pushes a batch of events to the Historian and expects the first Entry it reads to be the one that contains the events it just pushed. That's broken! Instead, find a different way to get all Entry IDs registered with the accountant. EventProcessor is the wrong place to intercept those entries.
The text was updated successfully, but these errors were encountered: