aboutsummaryrefslogtreecommitdiff
path: root/src/client/context.rs
diff options
context:
space:
mode:
authorZeyla Hellyer <[email protected]>2017-09-18 18:10:12 -0700
committerZeyla Hellyer <[email protected]>2017-09-18 18:10:12 -0700
commit7c4b052d7b5a50f234721249bd0221f037e48ea9 (patch)
tree03e7637731782f72ff1490747019491194167b54 /src/client/context.rs
parenttravis: don't test rustfmt (diff)
downloadserenity-7c4b052d7b5a50f234721249bd0221f037e48ea9.tar.xz
serenity-7c4b052d7b5a50f234721249bd0221f037e48ea9.zip
Fix block on spawning multiple shards
When spawning multiple shards (via an equal number of futures - one per shard) joined on a core.run use, the very first future executed would block forever due to a sync, blocking `monitor_shard` use. While this defeats the purpose of tokio, this was meant to be a first step to an async serenity implementation. To "fix" this blocking call until a deeper async implementation is made, spawn a new thread per tokio core (and thus per shard). This causes the same expected behaviour, just with multiple threads like before.
Diffstat (limited to 'src/client/context.rs')
-rw-r--r--src/client/context.rs1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/client/context.rs b/src/client/context.rs
index 9ed3652..614f79a 100644
--- a/src/client/context.rs
+++ b/src/client/context.rs
@@ -400,6 +400,7 @@ impl Context {
/// [`Client::start`]: ./struct.Client.html#method.start
pub fn quit(&self) -> Result<()> {
let mut shard = self.shard.lock();
+
shard.shutdown_clean()
}
}