Asynchronous Channel Implementation in Rust

This challenge focuses on building a simple asynchronous channel in Rust using tokio. Asynchronous channels are fundamental for concurrent programming, allowing different tasks to communicate and synchronize without blocking each other. Implementing a basic channel will solidify your understanding of Rust's asynchronous features and tokio.

Problem Description

You are tasked with creating a basic asynchronous channel using tokio. The channel should allow sending and receiving messages asynchronously. The channel should be generic, capable of transmitting any type T. The core functionality includes:

• send(message: T): Asynchronously sends a message of type T through the channel. This function should not block the sender.
• recv(): Asynchronously receives a message from the channel. This function should return the received message when available. If the channel is empty, the receiver should wait until a message is sent.
• close(): Closes the channel, preventing further sends. Receiving from a closed channel should return an Err variant.

The channel should be implemented using tokio::sync::mpsc (multiple producer, single consumer) for efficient asynchronous communication. The close() method should signal to any waiting receivers that no more messages will be sent.

Key Requirements:

• The channel must be generic over the message type T.
• send() and recv() must be asynchronous functions.
• close() must prevent further sends and signal receivers.
• Receiving from a closed channel must return an Err result.
• Use tokio::sync::mpsc for the underlying channel implementation.

Expected Behavior:

• Multiple senders can send messages to the channel concurrently.
• Only one receiver can receive messages from the channel at a time.
• The receiver should block until a message is available or the channel is closed.
• After the channel is closed, any further attempts to send should panic (as mpsc does).
• Receiving from a closed channel should return an Err result.

Edge Cases to Consider:

• What happens if the receiver attempts to receive from an empty channel? It should block.
• What happens if the channel is closed while a receiver is waiting? The receiver should receive an Err result.
• What happens if the channel is closed and another sender attempts to send? mpsc will panic, and your code should handle this gracefully (though explicit error handling beyond the panic is not required for this challenge).

Examples

Example 1:

Input:
- Sender sends "Hello"
- Sender sends "World"
- Receiver receives twice
Output:
Receiver receives "Hello", then "World"
Explanation: The receiver blocks until each message is sent.

Example 2:

Input:
- Sender sends "Message 1"
- Channel is closed
- Receiver receives once
Output:
Receiver receives "Message 1", then returns an Err result.
Explanation: The receiver receives the last message before the channel is closed, then receives an error.

Example 3: (Edge Case)

Input:
- Channel is closed immediately after creation.
- Receiver attempts to receive.
Output:
Receiver immediately returns an Err result.
Explanation: The channel is closed before any messages are sent.

Constraints

• The solution must use tokio for asynchronous operations.
• The solution must use tokio::sync::mpsc for the underlying channel.
• The channel must be generic over the message type T.
• The send() function should not block the sender.
• The recv() function should return a Result<T, Error> where Error is a simple enum indicating channel closure.
• The close() function should prevent further sends.
• The solution should compile and run without panicking (except for mpsc panics on send after close).

Notes

• Consider using async/await for asynchronous operations.
• The tokio::sync::mpsc channel provides a convenient way to implement asynchronous communication.
• Think about how to signal to the receiver that the channel is closed. mpsc handles this internally.
• Focus on the core functionality of sending, receiving, and closing the channel. Error handling beyond the Result return from recv() is not required.
• You will need to add tokio = { version = "1", features = ["full"] } to your Cargo.toml file.