Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does handler need to be Sync? #205

Open
Reconcyl opened this issue Feb 14, 2019 · 2 comments
Open

Why does handler need to be Sync? #205

Reconcyl opened this issue Feb 14, 2019 · 2 comments

Comments

@Reconcyl
Copy link

I have a situation where I want to pass a sender to the request handler:

use std::sync::mpsc::Sender;
let tx: Sender<Foo> = get_sender();
rouille::start_server(ADDR, move |req| handle(req, tx.clone()));

Unfortunately, this doesn't work because unlike std::thread::spawn, start_server(addr, handler) requires that handler is Sync.

Why is this the case? Is there any way to get around it without resorting to a Mutex?

@LPGhatguy
Copy link

I actually ran into this exact case today!

Rouille uses a thread pool internally, which means that multiple requests could be happening simultaneously. That concurrent access means that any types you access from your handler need to be Sync!

@leshow
Copy link

leshow commented May 20, 2020

Hi, I ran into this issue too. The problem, from what I can tell, is that there is no way to actually clone a Sender such that you can move it into one of the threads that will process a request.

Often in cases like these, you can get around it by cloning then moving in an extra block:

{
    let tx = chan.clone();
    move |req| {
        // use tx
     }
}

But even this doesn't appear to work. There should be a way to share Sender clones to request handlers. Is there any workaround in place here except for adding an extra Mutex on the Sender?

The send method only takes Sender by &self so it feels very unfortunate and almost like a bug to have to stick it in a Mutex.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants