Async versions for Reader and Writer

[splix]

I'm wondering if there are any plans (or opposition to those) for async implementation for Reader and Writer? I.e., a reader from tokio::io::AsyncRead, etc

[splix]

I've tried to add it, but quickly realized that it requires [mostly] duplicate versions for too many of internal functions.

Like for

pub fn zag_i64<R: Read>(reader: &mut R) -> AvroResult<i64> {
    let z = decode_variable(reader)?;
    Ok(if z & 0x1 == 0 {
        (z >> 1) as i64
    } else {
        !(z >> 1) as i64
    })
}

it needs an accompanying:

#[cfg(feature = "tokio")]
pub async fn zag_i64_async<R: AsyncRead>(reader: &mut R) -> AvroResult<i64> {
    let z = decode_variable_async(reader).await?;
    Ok(if z & 0x1 == 0 {
        (z >> 1) as i64
    } else {
        !(z >> 1) as i64
    })
}

and so on.

It's definitely possible to implement, but the main question if that aligns well with avro-rs plans?

[martin-g]

Duplicating the code is no go.

IMO a more feasible way is to make everything async and use a same-thread thread pool for sync usage. But I haven't seen any other library doing it so probably I miss something.

[splix]

For this particular example it's possible to move out the duplicate part into an inline function, and keep only decode_variable_async(reader).await?; and decode_variable_async(reader)?; depending on the variant. Another option is wrapping those with some macros which depending on the compilation target adds .await or not. Anyway, I agree that both options are bit ugly.

Or actually I think that many functions like this one could be transformed to something more universal which could work in both ways. I'm worried mostly about the fact that too many things must be touched to support async.

[splix]

Regarding the sync usage, there is https://docs.rs/tokio-util/0.7.4/tokio_util/io/struct.SyncIoBridge.html that allows it