theduke
commented
4 years ago I don't think we'll be able to fit !Send futures into the design, even with a feature. Things are already a bit messy with GraphQLTypeAsync layered on top of GraphQLType (this might change a a bit in the future).
Supporting !Send futures would require all resolved Futures to be without the Send bound and would be restricted to one thread.
I don't really see a lot of use cases where this would be sensible.
Your use case seems to be dealing with a synchronous database connection? You can't (well, shouldn't) use those anyway in a async environment, since you are not supposed to block a executor thread for longer periods.
Longer synchronous operations need to be delegated to a thread pool. Which is totally sensible for database queries if your DB api does not support async (yet).
Below is a super simple (suboptimal) code snippet as an example for such a threadpool that I wipped up last week. I'm sure a good crate with a better implementation will emerge pretty soon.
#[derive(Clone)]
pub struct SyncThreadPool {
pool: Arc<Mutex<threadpool::ThreadPool>>,
}
impl SyncThreadPool {
pub fn new(threads: usize) -> Self {
let pool = threadpool::ThreadPool::new(threads);
Self {
pool: Arc::new(Mutex::new(pool)),
}
}
pub async fn execute<T, F>(&self, f: F) -> Result<T, failure::Error>
where
T: Send + 'static,
F: FnOnce() -> T + Send + 'static,
{
let (tx, rx) = futures::channel::oneshot::channel();
let wrapped = move || {
let output = f();
tx.send(output)
.map_err(|_| ())
.expect("Could not send completion message");
};
self.pool.lock().unwrap().execute(wrapped);
rx.await
.map_err(|_| failure::format_err!("Pool execution failed"))
}
}
tyranron
LegNeato
Is your feature request related to a problem? Please describe. Sometimes it's necessary to run not
Sendfuture in juniper handler (for example to get data from database). However, when trying to run such future I get the following error:Describe the solution you'd like It would be nice to be able to use an option to use
!Sendfutures in juniper, ideally with?Sendoption on#[juniper::object]macro (like in async_trait )I have tried removing Send bound from everywhere and it works fine, but then it's not possible to use futures from juniper as
Sendfutures (for example, I cannot callreq.execute_async(schema, context).boxed().await)I don't think that it would be possible to have such option on
#[juniper::object]macro becauseSendmarker is defined in trait, not in it's implementantion. I think it could be done with a cargo.toml feature, but then it won't be possible to use bothSendand!Sendfutures in one projectDescribe alternatives you've considered I have considered changing database connection function, but it decreases performance