re: Are async frameworks really worth it? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: My use case was running it in gtk::idle_add/timeout_add, which only supports non-blocking calls (it was run on the same thread). It was also to rea...

Alright, you're making some good points. I suppose I should see if I can use GTK+'s reactor to read a connection. Doubt it, but perhaps.

In your example though, I don't see why you couldn't just make the connection vector hold a type parameter and add the second request with another type.

In your example though, I don't see why you couldn't just make the connection vector hold a type parameter and add the second request with another type.

You mean something like this?

fn next_available() -> (usize, i64) {
    for (i, (orig_index, request)) in remaining_requests.iter().enumerate() {
        if Some(response) = request.try_read() {
            remaining_requests.remove(i);
            return Some((orig_index, match request {
                FirstRequest(..) => FirstResponse(response),
                SecondRequest(..) => SecondResponse(response),
            }));
        }
    }
    None
}

if let Some(i, response) = next_available() {
    match response {
        FirstResponse(response) => {
            send_second_request(response.data);
        },
        SecondResponse(response) {
            result[i] = response.data;
        },
    }
}

It doesn't scale very well:

  • You need, for each IO in the algorithm, to add a branch to the enum.
  • Code sequence that normally goes together needs to be broken to different places.
  • If you want to add other algorithms on the same loop, it's hard to keep them from tangling with each other.
code of conduct - report abuse