zecfoundation
/
zebra
mirror of https://github.com/ZcashFoundation/zebra.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zebra/tower-batch/src/message.rs

18 lines
490 B
Rust
Raw Normal View History

Revert #500 (generic errors in tower-batch). Unfortunately, since the Batch wrapper was changed to have a generic error type, when wrapping it in another Service, nothing constrains the error type, so we have to specify it explicitly to avoid an inference hole. This is pretty unergonomic -- from the compiler error message it's very unintuitive that the right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`. The options are: 1. roll back the changes that make the error type generic, so that the error type is a concrete type; 2. keep the error type generic but hardcode the error in the default constructor and add an additional code path that allows overriding the error. However, there's a further issue with generic errors: the error type must be Clone. This problem comes from the fact that there can be multiple Batch handles that have to share access to errors generated by the inner Batch worker, so there's not a way to work around this. However, almost all error types aren't Clone, so there are fairly few error types that we would be swapping in. This suggests that in case (2) we would be maintaining extra code to allow generic errors, but with restrictive enough generic bounds to make it impractical to use generic error types. For this reason I think that (1) is a better option.
2020-07-15 21:42:57 -07:00
use super::error::ServiceError;
tower-batch: copy tower-buffer source code. There's a lot of functional overlap between the batch design and tower-buffer's existing internals, so we'll just vendor its source code and modify it. If/when we upstream it, we can deduplicate common components.
2020-06-12 10:22:08 -07:00
use tokio::sync::oneshot;
tower-batch: initial implementation of batching logic. The name "Buffer" is changed to "Batch" everywhere, and the worker task is rewritten. Instead of having Worker implement Future directly, we have a consuming async run() function.
2020-06-12 11:42:28 -07:00
/// Message sent to the batch worker
tower-batch: copy tower-buffer source code. There's a lot of functional overlap between the batch design and tower-buffer's existing internals, so we'll just vendor its source code and modify it. If/when we upstream it, we can deduplicate common components.
2020-06-12 10:22:08 -07:00
#[derive(Debug)]
Revert #500 (generic errors in tower-batch). Unfortunately, since the Batch wrapper was changed to have a generic error type, when wrapping it in another Service, nothing constrains the error type, so we have to specify it explicitly to avoid an inference hole. This is pretty unergonomic -- from the compiler error message it's very unintuitive that the right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`. The options are: 1. roll back the changes that make the error type generic, so that the error type is a concrete type; 2. keep the error type generic but hardcode the error in the default constructor and add an additional code path that allows overriding the error. However, there's a further issue with generic errors: the error type must be Clone. This problem comes from the fact that there can be multiple Batch handles that have to share access to errors generated by the inner Batch worker, so there's not a way to work around this. However, almost all error types aren't Clone, so there are fairly few error types that we would be swapping in. This suggests that in case (2) we would be maintaining extra code to allow generic errors, but with restrictive enough generic bounds to make it impractical to use generic error types. For this reason I think that (1) is a better option.
2020-07-15 21:42:57 -07:00
pub(crate) struct Message<Request, Fut> {
tower-batch: copy tower-buffer source code. There's a lot of functional overlap between the batch design and tower-buffer's existing internals, so we'll just vendor its source code and modify it. If/when we upstream it, we can deduplicate common components.
2020-06-12 10:22:08 -07:00
pub(crate) request: Request,
Revert #500 (generic errors in tower-batch). Unfortunately, since the Batch wrapper was changed to have a generic error type, when wrapping it in another Service, nothing constrains the error type, so we have to specify it explicitly to avoid an inference hole. This is pretty unergonomic -- from the compiler error message it's very unintuitive that the right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`. The options are: 1. roll back the changes that make the error type generic, so that the error type is a concrete type; 2. keep the error type generic but hardcode the error in the default constructor and add an additional code path that allows overriding the error. However, there's a further issue with generic errors: the error type must be Clone. This problem comes from the fact that there can be multiple Batch handles that have to share access to errors generated by the inner Batch worker, so there's not a way to work around this. However, almost all error types aren't Clone, so there are fairly few error types that we would be swapping in. This suggests that in case (2) we would be maintaining extra code to allow generic errors, but with restrictive enough generic bounds to make it impractical to use generic error types. For this reason I think that (1) is a better option.
2020-07-15 21:42:57 -07:00
pub(crate) tx: Tx<Fut>,
tower-batch: copy tower-buffer source code. There's a lot of functional overlap between the batch design and tower-buffer's existing internals, so we'll just vendor its source code and modify it. If/when we upstream it, we can deduplicate common components.
2020-06-12 10:22:08 -07:00
pub(crate) span: tracing::Span,
deps: move to tokio 0.3, tower 0.4 This change is mostly mechanical, with the exception of the changes to the `tower-batch` middleware. This middleware was adapted from `tower::buffer`, and the `tower::buffer` code was changed to implement its own bounded queue, because Tokio 0.3 removed the `mpsc::Sender::poll_send` method. See https://github.com/tower-rs/tower/commit/ddc64e8d4d4d499adef569e284f317288edd6513 for more context on the Tower changes. To match Tower as closely as possible in order to be able to upstream `tower-batch`, those changes are copied from `tower::Buffer` to `tower-batch`.
2020-11-19 11:54:20 -08:00
pub(super) _permit: crate::semaphore::Permit,
tower-batch: copy tower-buffer source code. There's a lot of functional overlap between the batch design and tower-buffer's existing internals, so we'll just vendor its source code and modify it. If/when we upstream it, we can deduplicate common components.
2020-06-12 10:22:08 -07:00
}
/// Response sender
Revert #500 (generic errors in tower-batch). Unfortunately, since the Batch wrapper was changed to have a generic error type, when wrapping it in another Service, nothing constrains the error type, so we have to specify it explicitly to avoid an inference hole. This is pretty unergonomic -- from the compiler error message it's very unintuitive that the right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`. The options are: 1. roll back the changes that make the error type generic, so that the error type is a concrete type; 2. keep the error type generic but hardcode the error in the default constructor and add an additional code path that allows overriding the error. However, there's a further issue with generic errors: the error type must be Clone. This problem comes from the fact that there can be multiple Batch handles that have to share access to errors generated by the inner Batch worker, so there's not a way to work around this. However, almost all error types aren't Clone, so there are fairly few error types that we would be swapping in. This suggests that in case (2) we would be maintaining extra code to allow generic errors, but with restrictive enough generic bounds to make it impractical to use generic error types. For this reason I think that (1) is a better option.
2020-07-15 21:42:57 -07:00
pub(crate) type Tx<Fut> = oneshot::Sender<Result<Fut, ServiceError>>;
tower-batch: copy tower-buffer source code. There's a lot of functional overlap between the batch design and tower-buffer's existing internals, so we'll just vendor its source code and modify it. If/when we upstream it, we can deduplicate common components.
2020-06-12 10:22:08 -07:00
/// Response receiver
Revert #500 (generic errors in tower-batch). Unfortunately, since the Batch wrapper was changed to have a generic error type, when wrapping it in another Service, nothing constrains the error type, so we have to specify it explicitly to avoid an inference hole. This is pretty unergonomic -- from the compiler error message it's very unintuitive that the right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`. The options are: 1. roll back the changes that make the error type generic, so that the error type is a concrete type; 2. keep the error type generic but hardcode the error in the default constructor and add an additional code path that allows overriding the error. However, there's a further issue with generic errors: the error type must be Clone. This problem comes from the fact that there can be multiple Batch handles that have to share access to errors generated by the inner Batch worker, so there's not a way to work around this. However, almost all error types aren't Clone, so there are fairly few error types that we would be swapping in. This suggests that in case (2) we would be maintaining extra code to allow generic errors, but with restrictive enough generic bounds to make it impractical to use generic error types. For this reason I think that (1) is a better option.
2020-07-15 21:42:57 -07:00
pub(crate) type Rx<Fut> = oneshot::Receiver<Result<Fut, ServiceError>>;