Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

send functions should take a reference of message &M #104

Open
tqwewe opened this issue Mar 1, 2023 · 2 comments
Open

send functions should take a reference of message &M #104

tqwewe opened this issue Mar 1, 2023 · 2 comments

Comments

@tqwewe
Copy link
Member

tqwewe commented Mar 1, 2023

Sending messages should not require ownership of the message being sent.

For example, the send method on Process has the following signature:

pub fn send(&self, message: M);

This should be taking a reference of M:

pub fn send(&self, message: &M);

Though this would be a breaking change.

One solution which may keep it as non-breaking would be to take impl AsRef<M>.
Though I'm not sure if every implementation of AsRef is compatible to ser/de in bincode. There is also the possibility of the Borrow trait, though I'm also not sure if everything implemented is compatible with bincode.

@tqwewe tqwewe changed the title Send functions should take a reference of message M send functions should take a reference of message M Mar 1, 2023
@tqwewe tqwewe changed the title send functions should take a reference of message M send functions should take a reference of message &M Mar 1, 2023
@bkolobara
Copy link
Contributor

Resources make this a bit more complicated.

The reason why we don't take a reference is that some resources are moved out of the process into the message during serialization. This makes it unsafe to serialize them two times. I admit that this is not the most elegant way of coupling things, but I couldn't come up with a better solution.

We could solve this for example by just cloning resources during serialization and move the cloned ones into the message. This however would require all resources to be Clone. I'm not sure if this is true for all resources (e.g. listening socket) that can be sent between processes.

@tqwewe
Copy link
Member Author

tqwewe commented Mar 2, 2023

Hmm I see, I think it might be worth looking into, since giving a reference when sending messages would strip out a bunch of cloning I would imagine. I'm not sure which resources might not be Clone. TcpListener doesn't seem to even be Serializable.
I like the solution of cloning within the serialization implementation, since most resources are just integer identifiers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants