What's the best way to close a broadcast channel?

[estigma88]

Hi everyone, I have the following pseudocode:

pub struct Test {
    sender: Sender<usize>
}

impl Test {
    pub(crate) fn new() -> Self {
        let (sender, _) = broadcast::channel::<usize>(100);

        Self {
            sender: sender,
        }
    }

    async fn write(&self, buf: usize) {
        self.sender.send(buf)
		
	// Do other stuff
		
	// Close the sender as if a condition was met
    }
	
    async fn read(&self) {
	let mut receiver = self.sender.subscribe();
	   
	let value = receiver.recv();
	   
	// Do other stuff
    }
}

Where:

• We create a channel, saving the Sender as a struct variable.
• We have a write method, called by only one thread/task, which uses the Sender to send values.
• We have a read method, called by many threads/tasks, which subscribes to the Sender and waits for values to come.

The main concern is on line let value = receiver.recv();, if the writer ends and no more values are sent, but new readers come, that line will block forever, waiting for new values to appear in the broadcast channel.

The solution is to close the channel/sender, as I expect the lock to be released with a Closed message, but AFAIK the only way to close the Sender is to drop it.

As we have the Sender as an instance variable of the struct, I am not sure how to drop it, also, there is no close() method available that we can use instead of dropping the object.

Any help would be appreciated.

[Noah-Kennedy]

You can make the field an Option<Sender>

[estigma88]

Yeah, I saw that as a posibility, but feels weird, as I will need to wrap it in a RwLock, something like RwLock<Option<Sender>>. Feels weird because Sender is already thread safe, but Option.take() is not, so, it is required to wrap it in a thread safe utility like RwLock to be able to mutate it....

For me having a close() method feels more natural, as Sender is already thread safe and should be able to handle the close operation (this is obviosly from my view with little knowledge of the implementation details :))

[Darksonn]

The requests to add all sorts of features to the channels keep going on forever. We have to push back to avoid making them too complicated.

[Noah-Kennedy]

You could also use ArcSwap to do this without a lock.

[estigma88]

Wow, didn't know about ArcSwap, thanks for the responses

[Noah-Kennedy]

No problem!