diff options
| author | Zeyla Hellyer <[email protected]> | 2017-09-18 18:10:12 -0700 |
|---|---|---|
| committer | Zeyla Hellyer <[email protected]> | 2017-09-18 18:10:12 -0700 |
| commit | 7c4b052d7b5a50f234721249bd0221f037e48ea9 (patch) | |
| tree | 03e7637731782f72ff1490747019491194167b54 /src/client/dispatch.rs | |
| parent | travis: don't test rustfmt (diff) | |
| download | serenity-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.rs | 2 |
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) { |