[dev] fix windows builds and timeouts

[EverlastingBugstopper]

This fixes the issues we were having with logs not working on windows!

[EverlastingBugstopper]

keepalive timer requires that we send a heartbeat message every so often and i'm gonna need tokio-tungstenite for that. probably for the best as it seems to be the recommended websocket library and their master branch has support for async/await

[EverlastingBugstopper]

One thing I have a question about is my use of two separate tokio runtimes here. I'm wondering if there's a better pattern I should be using.

[EverlastingBugstopper]

I think this might fix #888

[steveklabnik]

Yeah, two runtimes aren't ideal. I haven't dug into the code yet but https://docs.rs/tokio/0.2.9/tokio/task/fn.spawn.html is probably what you'd do

[EverlastingBugstopper]

So it turns out this builds on Windows but seems to not read incoming socket messages. I've opened this issue to see if the awesome folks over at tokio-tungstenite have any ideas.

[EverlastingBugstopper]

@steveklabnik re: your comment about spawn

The following code starts and ends the process almost immediately, it seems to spawn the two tasks and then exit.

    let mut runtime = TokioRuntime::new().unwrap();

    // listen for devtools messages
    runtime.spawn(async move {
        socket::listen(session_id).await
    });

    // handle incoming HTTP requests
    runtime.spawn(async move {
        serve(server_config, preview_id).await
    })?;

The following code seems to work at first, provides a "Listening" message, but fails to handle any incoming HTTP requests:

    let mut runtime = TokioRuntime::new().unwrap();

    // listen for devtools messages
    runtime.spawn(async move {
        socket::listen(session_id).await
    });

    // handle incoming HTTP requests
    runtime.block_on(async move {
        serve(server_config, preview_id).await
    })?;

[steveklabnik]

I believe that's because of this:

that is, your runtime goes out of scope at the end of the function, and so shuts down.

[EverlastingBugstopper]

I seem to have cracked the code thanks to some help from the friendly Tokio discord server :) - only one runtime now

[steveklabnik]

This looks good! I have a few questions/comments but in general, I approve :)

[steveklabnik]

🎊

[steveklabnik]

any reason to not

let _ =

instead?

[steveklabnik]

also, are you sure that ignoring all failures is what you want here?

[EverlastingBugstopper]

That's a good point - I'm going to add some .unwrap() calls to them. Not quite sure if there's a way for me to bubble up those failures through the async fn

[steveklabnik]

pub fn block_on<F: Future>(&mut self, future: F) -> F::Output

should return that Result back out of block_on, I think.

[EverlastingBugstopper]

very interesting - i think i got it

[steveklabnik]

might be worth giving this a return type of !

[EverlastingBugstopper]

Interesting! I'm not familiar with this syntax and can't seem to find an example of a function returning ! - would you mind elaborating?

[steveklabnik]

https://doc.rust-lang.org/stable/book/ch19-04-advanced-types.html#the-never-type-that-never-returns

[steveklabnik]

(loop has the type !, but since ! coerces to any other type, it coerces to the return type of () here, which is why this code works the way it does)

[EverlastingBugstopper]

this is very cool

[steveklabnik]

i am interested why this is 2. not because it's wrong, but it feels unusual! Might deserve a comment

[EverlastingBugstopper]

Fair point - the reason it's 2 is because we have already sent id = 1 earlier to enable the runtime. Eventually I plan on making the ID handling automatic and in the chrome-devtools-rs library.

[EverlastingBugstopper]

thanks steve!