Implementing a Broadcast Channel in Rust

Broadcast channels are a powerful concurrency primitive allowing multiple receivers to receive the same data sent by a single sender. This is useful in scenarios like distributing updates to multiple UI components, notifying multiple subscribers to a data stream, or implementing a pub/sub system. Your task is to implement a basic broadcast channel in Rust using channels and threads.

Problem Description

You need to implement a BroadcastChannel struct in Rust that allows multiple receivers to subscribe to a single sender. The BroadcastChannel should provide the following functionalities:

• send(message: T): Sends a message of type T to all subscribed receivers.
• subscribe(): Returns a receiver that receives all messages sent through the channel. Multiple calls to subscribe() will return multiple independent receivers.
• unsubscribe(receiver: Receiver<T>): Removes a receiver from the channel's subscriber list. This function should not panic if the receiver is not subscribed.

The implementation should use Rust's standard mpsc (multiple producer, single consumer) channels internally to manage message distribution. A separate thread should be responsible for receiving messages from the internal sender and broadcasting them to all subscribed receivers.

Key Requirements:

• Multiple Receivers: The channel must support multiple concurrent receivers.
• Message Broadcasting: All subscribed receivers must receive the same messages.
• Thread Safety: The BroadcastChannel must be thread-safe, allowing multiple senders and receivers to interact concurrently.
• Unsubscribe Functionality: Receivers should be able to unsubscribe from the channel.
• No Data Loss: All messages sent should be delivered to all subscribed receivers (unless a receiver unsubscribes after receiving a message).

Expected Behavior:

• When a message is sent, all currently subscribed receivers should receive it.
• Unsubscribing a receiver should prevent it from receiving further messages.
• The channel should handle concurrent sends and receives gracefully.
• The channel should not leak threads.

Edge Cases to Consider:

• Sending messages after all receivers have unsubscribed. (The sender thread should terminate gracefully.)
• Unsubscribing a receiver that has already received a message.
• Concurrent sends and receives.
• Multiple receivers subscribing and unsubscribing concurrently.

Examples

Example 1:

Input:
Sender:
send("Hello");
send("World");

Receiver 1: subscribe()
Receiver 2: subscribe()

Output (Receiver 1): "Hello", "World"
Output (Receiver 2): "Hello", "World"
Explanation: Both receivers subscribe and receive both messages sent by the sender.

Example 2:

Input:
Sender:
send("First");
send("Second");

Receiver 1: subscribe()
Receiver 2: subscribe()
Receiver 1: unsubscribe()
send("Third");

Output (Receiver 1): "First", "Second"
Output (Receiver 2): "First", "Second", "Third"
Explanation: Receiver 1 subscribes, receives "First" and "Second", then unsubscribes. Receiver 2 receives all three messages.

Example 3: (Edge Case - No Receivers)

Input:
Sender:
send("Message");

Receiver 1: subscribe()
Receiver 1: unsubscribe()
send("Another Message");

Output (Receiver 1): (None)
Explanation: The sender attempts to send messages after all receivers have unsubscribed. The sender thread should terminate gracefully without panicking.

Constraints

• The BroadcastChannel should be generic over the message type T.
• The internal channel should be mpsc::Sender and mpsc::Receiver.
• The sender thread should terminate gracefully when there are no more subscribers.
• The solution should be reasonably efficient (avoid unnecessary copying or allocations).
• The solution should not use external crates beyond the Rust standard library.
• The send function should not block indefinitely.

Notes

• Consider using Arc<Mutex<Vec<Receiver<T>>>> to manage the list of receivers safely across threads.
• The sender thread should continuously check if there are any subscribers before sending messages.
• Think about how to handle the case where a receiver panics while receiving a message. (For simplicity, you can ignore this in this basic implementation.)
• Focus on correctness and thread safety first. Performance optimizations can be considered later.
• The unsubscribe function should not panic if the receiver is not found in the list. It should simply do nothing.