aboutsummaryrefslogtreecommitdiff
path: root/src/client/dispatch.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/dispatch.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/dispatch.rs')
-rw-r--r--src/client/dispatch.rs2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/client/dispatch.rs b/src/client/dispatch.rs
index 494ab6d..490f4b6 100644
--- a/src/client/dispatch.rs
+++ b/src/client/dispatch.rs
@@ -45,7 +45,7 @@ fn context(conn: &Arc<Mutex<Shard>>, data: &Arc<Mutex<ShareMap>>, handle: &Handl
#[cfg(feature = "framework")]
pub fn dispatch<H: EventHandler + 'static>(event: Event,
conn: &Arc<Mutex<Shard>>,
- framework: &Arc<sync::Mutex<Option<Box<Framework>>>>,
+ framework: &Arc<sync::Mutex<Option<Box<Framework + Send>>>>,
data: &Arc<Mutex<ShareMap>>,
event_handler: &Arc<H>,
tokio_handle: &Handle) {