struct WithRes<R, Fut: Future<Output=R>> {
res_ptr: *mut R,
fut: Fut
}
impl<R, Fut: Future<Output=R>> WithRes<R, Fut> {
fn new(res_ptr: *mut R, fut: Fut) -> Self {
Self { res_ptr, fut }
}
}
impl<R, Fut: Future<Output=R>> Future for WithRes<R, Fut> {
type Output = ();
fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
let this = unsafe { self.get_unchecked_mut() };
let mut pinned = unsafe { Pin::new_unchecked(&mut this.fut) };
match pinned.as_mut().poll(cx) {
Poll::Pending => Poll::Pending,
Poll::Ready(res) => {
unsafe { this.res_ptr.write(res) };
Poll::Ready(())
}
}
}
}Корутина (сопрограмма) — это блок кода, который работает асинхронно, то есть по очереди.
получить запрос -> отправить его в очередь -> встать в ожидание ответа из очереди
Но ведь это означает 2 передачи одного файла: от хранилища к сервису, и от сервиса к клиенту. Очевидно, что в случаях, когда производительность некритична, это будет работать. Так же, очевидно, это верное решение, если нужно как-то изменить файлы перед отдачей. Однако, если файлы перед отдачей изменять не надо, почему бы не разрешить пользователям обращаться к хранилищу?
Не воспринимайте мои слова, как высмеивание вашего подхода или любую другую форму агрессии. Я лишь студент, который не имеет опыта эксплуатации большой СХД. Однако, я хочу получить максимально полные знания, поэтому хочу спросить Вас, почему ваша компания и многие другие выбрали именно такую архитектуру?