Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant