Rust Notification System

This challenge involves building a foundational notification system in Rust. You'll create a mechanism to send and manage simple notifications, simulating a common feature in many applications where users need to be informed of events or updates. This exercise will test your understanding of Rust's concurrency primitives and error handling.

Problem Description

Your task is to implement a Notifier struct that can:

1. Register Subscribers: Allow multiple "subscribers" (represented by closures) to register for notifications.
2. Send Notifications: Broadcast a message to all currently registered subscribers.
3. Unregister Subscribers: Allow subscribers to be removed from the notification list.

The Notifier should be thread-safe, allowing multiple threads to register and send notifications concurrently without data races.

Key Requirements:

• A Notifier struct should be defined.
• A method register to add a subscriber. A subscriber should be a function or closure that accepts a String (the notification message).
• A method notify to send a String message to all registered subscribers.
• A method unregister to remove a specific subscriber. For simplicity, we can assume subscribers are identified by a unique ID or that the unregister method can accept the subscriber itself (though managing identity for closures can be tricky, we'll explore this). For this challenge, let's simplify by having register return a unique ID that unregister can use.
• The Notifier must be thread-safe.

Expected Behavior:

When notify is called with a message, each registered subscriber's closure should be invoked with that message. If a subscriber is unregistered, they should no longer receive notifications.

Edge Cases:

• Sending a notification when no subscribers are registered.
• Unregistering a subscriber that was never registered.
• Concurrent registration and unregistration while notifications are being sent.

Examples

Example 1:

Input:
let mut notifier = Notifier::new();
let sub1_id = notifier.register(|msg| println!("Subscriber 1 received: {}", msg));
let sub2_id = notifier.register(|msg| println!("Subscriber 2 received: {}", msg));

notifier.notify("Hello there!");
notifier.unregister(sub1_id);
notifier.notify("Another message.");
notifier.unregister(sub2_id);
notifier.notify("Final message.");

Output:
Subscriber 1 received: Hello there!
Subscriber 2 received: Hello there!
Subscriber 2 received: Another message.

Explanation:

1. Two subscribers are registered, each printing a prefixed message.
2. "Hello there!" is sent, received by both.
3. Subscriber 1 is unregistered.
4. "Another message." is sent, only received by Subscriber 2.
5. Subscriber 2 is unregistered.
6. "Final message." is sent, but there are no subscribers, so nothing is printed.

Example 2:

Input:
let mut notifier = Notifier::new();
notifier.notify("Initial broadcast."); // No subscribers

notifier.register(|msg| println!("User A: {}", msg));
notifier.notify("Second broadcast.");
notifier.unregister(0); // Assuming 0 is the ID of the first registered subscriber.
notifier.notify("Third broadcast.");

Output:
Second broadcast.
Third broadcast.

Explanation:

1. The first notify call does nothing as there are no subscribers.
2. A subscriber is registered.
3. "Second broadcast." is sent and received.
4. The subscriber is unregistered.
5. "Third broadcast." is sent, but the subscriber is gone, so nothing is printed.

Constraints

• The Notifier must be usable across multiple threads without causing data races.
• Subscriber closures should be able to capture their environment if needed (though for this example, simple closures are sufficient).
• The registration process should yield unique, identifiable IDs for each subscriber.
• The unregister method should efficiently remove a subscriber using their ID.
• The notify method should iterate over all currently registered subscribers without issues from concurrent modifications (registration/unregistration).

Notes

• Consider using Arc<Mutex<...>> or Arc<RwLock<...>> to make your Notifier thread-safe.
• When handling registrations and unregistrations concurrently with notifications, ensure that the collection of subscribers is accessed safely. A common pattern is to clone the list of subscribers before iterating to send notifications, allowing modifications to the main list while notifications are in progress.
• Think about how to store the subscribers. A HashMap mapping IDs to closures might be a good choice.
• For unregistering, ensure that the ID management is robust.
• The exact implementation of how closures are stored and invoked is up to you, but they must accept a String.

Good luck building your notification system!