opened
heifner
username_0
## Change Description

- Since `transaction_metadata` future is accessed from multiple threads, use a `shared_future` which is thread safe.
- Simplified `recover_key` usage and removed storage of `sig_cpu_usage` and `signing_keys` since they are stored in the `shared_future`.

## Consensus Changes
- [ ] Consensus Changes

## API Changes
- [ ] API Changes

## Documentation Additions
- [ ] Documentation Additions
Use shared_future - v1.7.x
issue
created
heifner
username_0
@username_1 To make `recover_keys` so that it could work without first calling `start_recover_keys`, `recover_keys` would need to take the `thread_pool` and `time_limit`. I just went with asserts for bad usage. I do think it is cleaner.
comment
created
arhag
username_1
@username_0 That's okay, but `recover_keys` signature would not need to change. If the future was not set up or did not match the requested chain ID, it would not try to do the recovery asynchronously. It would just compute the results right there with no time limit. Thus no need for `thread_pool` or `time_limit`.
comment