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

pipes::oneshot functions can't take channels/ports #4027

Closed
Aatch opened this issue Nov 24, 2012 · 2 comments
Closed

pipes::oneshot functions can't take channels/ports #4027

Aatch opened this issue Nov 24, 2012 · 2 comments

Comments

@Aatch
Copy link
Contributor

Aatch commented Nov 24, 2012

pipes::send_one and pipes::recv_one (and related functions) throw this error: copying a non-copyable variable.

This is the minimum code to reproduce it:

let (chan, port) = pipes::oneshot();
pipes::send_one(chan, true);

That will fail on the second line.

This is actually a big problem, since core::comm is deprecated I don't really have another way to do this kind of communication.

@Aatch
Copy link
Contributor Author

Aatch commented Nov 24, 2012

Ok, so I did a little more investigating. Moving the chan/port into the function works, however that does mean that you now can't use it inside a heap closure, as you cannot move out of a heap closure (like, oh, I don't know the most common way of spawning a new task).

I.E. This works:

let (chan, port) = pipes::oneshot();
pipes::send_one(move chan, true);

but this does not:

let (chan, port) = pipes::oneshot();
task::spawn |move chan| {
    pipes::send_one(chan, true);
    //pipes::send_one(move chan, true);// Neither work
}

I'm not sure how this should be fixed now though, since channels/ports shouldn't be copyable but you also need to handle the second case above. Maybe some liveness stuff?

@Aatch
Copy link
Contributor Author

Aatch commented Nov 24, 2012

Ahh, looks like this will stop being a problem once #2549 is done.

@Aatch Aatch closed this as completed Nov 24, 2012
RalfJung added a commit to RalfJung/rust that referenced this issue Nov 21, 2024
sync support: dont implicitly clone inside the general sync machinery
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

1 participant