5 ms·
Diesel is a synchronous library, so the post's database functions make a blocking call and then return a future which, of course, doesn't make them asynchronous
by always_good 9y ago
Diesel is a synchronous library, so the post's database functions make a blocking call and then return a future which, of course, doesn't make them asynchronous. They'd still block the event loop.
You could fix this by passing a `&futures_cpupool::CpuPool` into your database functions and wrapping the post's function bodies in `pool.spawn_fn(|| { ... })` so that they execute on a different thread and return a future of their result.
To have a global IO pool that you pass into fns, you can store it in the Service struct:
struct Microservice { io_pool: CpuPool }
Now you can access it in your service's handler (the call() fn) with `self.io_pool`.
- karavelov 9y agoOr use pg_async[1] that integrates with Futures/Tokio/Hyper. [1] https://crates.io/crates/pg_async https://crates.io/crates/pg_async
- anentropic 9y agoI've never touched Rust or Diesel... but what is the point of a synchronous library that makes blocking calls _and returns futures_? (I mean - why futures, if the call was blocking and presumably have a real result to return?)
- rejschaap 9y agoWild guess here, but it might make it compatible with frameworks or middleware that expects futures.
- Sean1708 9y agoDiesel doesn't return futures, the author of the blog post returned a future and the person that you commented on is pointing out that that's pointless because Diesel is synchronous.