Closed tecywiz121 closed 1 day ago
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.
Ah, thank you! That should work.
Couple of followup questions:
WriteQueue
? If I start multiple writes without it, will they end up interleaved and clobber each other?tokio-codec
simplify the implementation at all?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.
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.
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?
Update: as of https://github.com/capnproto/capnproto-rust/commit/0e825eecbf2337d1fb2caed015bfa4862a195d40, capnp_futures::write_queue
no longer uses Rc
and RefCell
, but the future returned by write_queue()
is still not Send
.
Found a better way in https://github.com/capnproto/capnproto-rust/commit/06cc7840805911de13d39203cf68696ee80ea330, and added some static assertions.
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 usetokio::spawn
becauseWriteQueue
has anRc<RefCell<_>>
in it.