capnp_futures::WriteQueue isn't Send

[tecywiz121]

I'm trying to use capnp_futures with tokio, but there aren't many examples around. I'm running into some difficulty when I try to schedule the future to write messages.

If I create a WriteQueue, I can't use tokio::spawn because WriteQueue has an Rc<RefCell<_>> in it.

[dwrensha]

I believe tokio still provides a way to spawn a future on the current thread. Does this work: https://docs.rs/tokio/0.1/tokio/runtime/current_thread/index.html ?

It might indeed make sense to make some of the stuff in capnp-futures more thread-friendly, though I have not yet had a need for that.

[tecywiz121]

Ah, thank you! That should work.

Couple of followup questions:

• What is the purpose of WriteQueue? If I start multiple writes without it, will they end up interleaved and clobber each other?
• Would using tokio-codec simplify the implementation at all?

[iduartgomez]

I was checking for issues like this, having a similar problem with the generated Reader and Builder types not being Send cannot be sent due to the raw pointers.

Is indeed not safe to implement Send for those? It would be pretty handy, even though there are workarounds can't send them to the normal, non-blocking, threadpool to do whatever work.

[iduartgomez]

This problem for example prevents working with capnp_futures seamlessly, as you run into a problem when trying to write insdie a spawn task, e.g.:

        let mut message = capnp::message::Builder::new_default();
        let mut data = message.init_root::<serialized_data::Builder>();
        data.set_msg(result);
        capnp_futures::serialize::write_message(writer, message)
            .await
            .unwrap()

Which is not very optimal.

[stabler]

I'm running into the same issue- I'm building a web service that spawns multiple threads to handle clients. I'm not sure how to work around this issue for that kind of application?