Currently we're using the MPSC channel from the futures crate as the underlying channel for sending messages to actors. This was because we originally needed a futures-aware channel so that we could .await on sending the message. Now that #11 has changed message sending to always complete synchronously, this functionality is no longer needed.
There are two main advantages to switching to crossbeam-channels would be:
Crossbeam's Senderonly needs &self to send, where futures's Senderneeds &mut self. This would allow us to change sending a message to only require &self, which in turn means that more user-defined message handlers can be written to take &self if they only send a message, which in turn opens up potential opportunities for parallelism.
Crossbeam has a single Sender type for both bounded and unbounded channels, which would make it easier for us to support configuring the size of an actor's message queue.
We should continue to use the oneshot channel provided by the futures crate for sending message responses, since it works well for our purposes and we actually benefit from using a futures-aware channel when sending a response.
Currently we're using the MPSC channel from the futures crate as the underlying channel for sending messages to actors. This was because we originally needed a futures-aware channel so that we could
.await
on sending the message. Now that #11 has changed message sending to always complete synchronously, this functionality is no longer needed.There are two main advantages to switching to crossbeam-channels would be:
Sender
only needs&self
to send, where futures'sSender
needs&mut self
. This would allow us to change sending a message to only require&self
, which in turn means that more user-defined message handlers can be written to take&self
if they only send a message, which in turn opens up potential opportunities for parallelism.Sender
type for both bounded and unbounded channels, which would make it easier for us to support configuring the size of an actor's message queue.We should continue to use the oneshot channel provided by the futures crate for sending message responses, since it works well for our purposes and we actually benefit from using a futures-aware channel when sending a response.