Implement a Multi-Producer, Single-Consumer Channel in Rust

This challenge asks you to implement a fundamental concurrency primitive: a Multi-Producer, Single-Consumer (MPSC) channel in Rust. MPSC channels are crucial for enabling safe communication between different threads, allowing multiple threads to send data to a single thread that receives and processes it. This pattern is widely used in concurrent programming for tasks like distributing work, collecting results, or managing event streams.

Problem Description

You need to implement a generic MPSC channel in Rust. This channel will consist of two main components: a sender and a receiver.

Sender: Multiple threads can hold a sender. Each sender should be able to send a value of a specified type T into the channel.
Receiver: Only one thread can hold the receiver. The receiver should be able to block until a value is available and then return it. If all senders are dropped, the receiver should eventually signal that no more messages will arrive.

Key Requirements:

Genericity: The channel should be generic over the type of data T it transmits.
Multiple Producers: It must be possible to create multiple sender handles from a single channel.
Single Consumer: Only one receiver handle can be created per channel.
Blocking Receive: The recv operation on the receiver should block the calling thread until a message is available or the channel is closed.
Channel Closure: When all sender handles are dropped, the channel should be considered closed. The recv operation should then return an error (or None in a more idiomatic Rust way) to indicate that no more messages will be sent.
Thread Safety: The implementation must be thread-safe, ensuring that sending and receiving operations can be performed concurrently from multiple threads without data races or deadlocks.

Expected Behavior:

When send is called on a sender, the value should be enqueued.
When recv is called on the receiver, it should return the oldest available value.
If recv is called when the channel is empty but there are still active senders, it should block.
If recv is called when the channel is empty and all senders have been dropped, it should return a value indicating the channel is closed (e.g., None if recv returns an Option<T>).

Edge Cases to Consider:

Empty Channel: What happens when recv is called on an empty channel with active senders?
Channel Closure: What happens when recv is called after all senders have been dropped?
Multiple Senders: How do you ensure that messages from multiple producers are handled correctly?
Sender Dropped: What happens if a sender is dropped before sending any messages?
Receiver Dropped: While the problem statement implies a single consumer, consider how the sender might behave if the receiver is dropped prematurely (though this might be out of scope if strictly adhering to "single consumer").

Examples

Example 1: Basic Sending and Receiving

use std::thread;
use std::time::Duration;

// Assume Channel::new(), sender.send(), receiver.recv() exist

let (tx, rx) = Channel::new(); // tx is a Sender, rx is a Receiver

let handle = thread::spawn(move || {
    tx.send(1).unwrap();
    thread::sleep(Duration::from_millis(10));
    tx.send(2).unwrap();
});

assert_eq!(rx.recv().unwrap(), 1);
assert_eq!(rx.recv().unwrap(), 2);

handle.join().unwrap();

Explanation: A sender tx and a receiver rx are created. A new thread is spawned, which sends two integers (1 and 2) into the channel with a small delay between them. The main thread receives these integers and asserts that they are received in the correct order.

Example 2: Multiple Producers

use std::thread;

// Assume Channel::new(), sender.send(), receiver.recv() exist

let (tx1, rx) = Channel::new();
let tx2 = tx1.clone(); // If your sender is cloneable

let handle1 = thread::spawn(move || {
    tx1.send(10).unwrap();
});

let handle2 = thread::spawn(move || {
    tx2.send(20).unwrap();
});

// The order of receiving 10 and 20 might vary depending on thread scheduling.
let mut received = vec![];
received.push(rx.recv().unwrap());
received.push(rx.recv().unwrap());
received.sort(); // Sort to make assertion predictable

assert_eq!(received, vec![10, 20]);

handle1.join().unwrap();
handle2.join().unwrap();

Explanation: Two sender handles (tx1 and tx2) are created (assuming Sender is Clone). Two separate threads send a value each. The receiver rx collects these values. The order of arrival isn't guaranteed, so we collect, sort, and then assert.

Example 3: Channel Closure

// Assume Channel::new(), sender.send(), receiver.recv() exist

let (tx, rx) = Channel::new();

let handle = thread::spawn(move || {
    tx.send(100).unwrap();
    // tx is dropped here when the thread exits
});

assert_eq!(rx.recv().unwrap(), 100);
// Now all senders (only tx in this case) are dropped.
// The next recv should indicate the channel is closed.
assert!(rx.recv().is_none()); // Or equivalent error/None return

handle.join().unwrap();

Explanation: A single sender sends a value. The sender is then dropped when its owning thread finishes. The receiver successfully receives the value. A subsequent call to recv on the now-closed channel returns None, indicating no more messages will be sent.

Constraints

The channel should support sending and receiving any type T that implements Send and 'static.
The implementation should be as efficient as possible, minimizing overhead.
Avoid using external crates for MPSC channels (e.g., std::sync::mpsc). You are implementing it from scratch.
The Sender type must be Cloneable to allow for multiple producers.

Notes

Consider using std::sync::Mutex or std::sync::Condvar to manage shared state and thread synchronization.
Think about how you will represent the channel's internal state (e.g., a queue for messages).
The recv method should return a type that can distinguish between a received value and the channel being closed. Option<T> is a common and idiomatic choice in Rust for this.
The send method should return a Result<(), SendError<T>> or similar to handle cases where the receiver has already been dropped (though this is less critical if strictly adhering to the "single consumer" and assuming it lives at least as long as the first message is sent). However, a robust implementation might consider this.
When a sender is cloned, ensure that all cloned senders refer to the same underlying channel.
The Receiver's Drop implementation should signal to any waiting senders or internal state that the receiver is gone, though for this specific problem, the primary concern is the receiver detecting when all senders are gone.