Better way than loop? (keeping a crossbeam_channel open)

So I'm curious. I'm writing a proxy using hyper (and other packages) that takes requests, hands them off for processing via crossbeam channels, then accepts a Request back and forwards it on.

The processing handler looks like this:

async fn core_handle(proxy_rx:crossbeam_channel::Receiver<proxy::ReqRes>, handler_tx: crossbeam_channel::Sender<proxy::ReqRes>){
    let core = CoreHandler::new(proxy_rx, handler_tx);
    loop{
        core.handle()
    }
    
}

The handle() function has all the processing in it, but in the end it just sends the finalized request back over the other channel.

So is there a better way to prevent the channel from getting closed, because bounded, unbounded, doesn't seem to matter. Without the loop, after the first send, the channel is closed. I feel like there's probably a better way, but I don't even know where to look.

You should probably use an async channel instead of crossbeam. Please see this article for an explanation why. I recommend the Tokio mpsc channel.

1 Like

why the async channel vs crossbeam? It wasn't obvious to me in the article what you're referring to.

Because the recv method of crossbeam does not use an await, yet it takes a long time if it has to wait for a message. Similar for send if the channel is full.

In your case, this extends to the fact that your core.handle() call has no .await, yet it probably takes a long time sometimes.

I'm guessing that the channel is not actually closed. Rather, the call to recv never gets to run because you ran out of threads by blocking on other crossbeam channels elsewhere or similar.

Actually, maybe I misread your question. A loop is the right choice for this kind of use-case.

Still, you should not be using crossbeam in async code for the previously mentioned reasons.

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.