Listening.close() does not close the server

[timonv]

I'm trying to run a hyper server, but after closing the guard, I can't drop it and it hangs. Here's some example code where it happens (sorry for the muda, was trying a ton of things)

fn request_temp_code() -> TempCode {
    Command::new("xdg-open").arg(format!("https://slack.com/oauth/authorize?client_id={}", SLACK_CLIENT_ID)).output().unwrap();
    let server = Server::http(Ipv4Addr(127, 0, 0, 1), 9999);

    let (tx, rx) = channel();
    let mtx = Mutex::new(tx);

    let mut guard = server.listen(move |req: Request, res: Response| {
        match req.uri {
            AbsolutePath(path) => {
                // Trying to manually drop to see if this is the problem
                let tempcode = extract_temp_code(&path).unwrap();
                let gmtx = mtx.lock().unwrap();
                gmtx.send(tempcode).unwrap();
                drop(gmtx);
            },
            _ => ()
        }

        let mut res = res.start().unwrap();
        res.write_all(b"Thanks! Please return to Lax").unwrap();
        res.end().unwrap();
    }).unwrap();

    let tempcode = rx.recv().unwrap();
    guard.close().unwrap();
    println!("{}", "Auth code received!");
    println!("{}", "Server closed!");
    // Hangs here
    tempcode
} 

I haven't tried this with earlier versions of hyper (I think, not tracking numbers), however one of the last commits did involve changes related to the thread spawning into the acceptor. Have I found a possible bug?

[timonv]

I also tried unparking the thread, to no avail. If I try to manually drop the guard after closing it, it hangs. I added some statements to check if multiple requests happen, nothing.

[reem]

Hmmm... It's likely that the guard returned by server.listen is incorrectly blocking for too long. I have to take another look at the code because this should work fine.

In order to facilitate fixing this, can you provide a standalone example that reproduces?

[timonv]

Sure! Let's see if I can do that in under ten minutes :-)

[timonv]

Ohh, close https://github.com/timonv/hyper_blocking_example

[reem]

From the code in your example I think it's very likely that the problem was some deadlock in your code mixing channels and mutexes, since there is no reason hyper would treat that function differently than any other.

Closing, unless you can reproduce (since I can't :/).

[timonv]

You can't? The example I gave doesn't work and reproduces the problem. :(

[timonv]

@reem Not sure if I need to mention for closed issues, but doing it anyway. Why would it deadlock? The mutex guard should be dropped right after the handler finishes it's shizzle. Is there anything else I can do to make this work? Maybe if Handler supported Copy I could just use an Arc.

I'd like to have this out of the way as its just the auth part of the project anyway :')

Edit: If its faster, I'm also on IRC.

[reem]

@timonv I looked at the example more closely and the issue is actually clear, I just didn't spot it before. The guard is created in get_message, so get_message is going to block until the entire server is done, have get_message also return the guard or create it in main to make things work.

[timonv]

@reem So I can't just create a server, get the token and ditch the server again? I can have the guard in the main loop sure, but that seems like an ugly and unneeded solution, as it would essentially keep the entire server open for the duration of the app. If it blocks untill the entire server is done, then you'd kinda expect it to stop over time.

[reem]

You can close the server by calling .close() on the guard. You should just do this after you receive the message, if you want to close the server right then.

[reem]

However, know that hyper runs servers with a thread pool by default, so you should take care to set the number of threads to 1.

[timonv]

@reem I was already closing the guard. I tried moving to a single thread for gigs yesterday but it didn't work. https://github.com/timonv/hyper_blocking_example/blob/master/src/main.rs

The weird thing is, if you print some giberish at the end of the handler, it gets printed. What could Thread::scoped's join guard be waiting for? No trouble dropping the mutex guard either.