Make Server core a RefCell

[tinco]

Make Server core a RefCell and introduce bind2 method that allows external core to be passed in

This is just an inspiration pull request. Do you see any problems with having core be a RefCell? I think it would be an insignificant overhead for posting new event handlers, but maybe I'm wrong and there's some tight loop that needs to dereference core?

[GitCop]

Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:

• Commit: 54baa36
• Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/hyperium/hyper/blob/master/CONTRIBUTING.md

---

This message was auto-generated by https://gitcop.com

[GitCop]

Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:

• Commit: 54baa36

• Commits must be in the following format: %{type}(%{scope}): %{description}

• Commit: a683af7

• Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/hyperium/hyper/blob/master/CONTRIBUTING.md

---

This message was auto-generated by https://gitcop.com

[seanmonstar]

Hi @tinco! Thanks for starting this up!

What is the goal here, for using a RefCell? Is this PR trying to address #1075?

[tinco]

Hi @seanmonstar :) Yes looks like #1075 is the sort of thing I'm trying to address. I'm trying to avoid any form of multithreading in my application, so would much prefer to have only a single Tokio core running. The idea of the Rc is that different pieces of code (with their own responsibilities) hold a reference to the core, and then the RefCell enables them to at any point borrow the core, get a handle and spawn some future on it.

I'm very much bending this API to my own selfish goal though, so I totally understand if this is not the right way for the project. Also, maybe some re-architecting could yield a more elegant solution. If there were some copyable interface to the event loop I could pass around that would be much better, but I don't know how that would work, maybe that's even something Tokio itself should think about?

[seanmonstar]

You may be wanting a Handle, which lets you handle.spawn(future) on it. You can get a Handler from hyper's Server:

let server = Http::new().bind(addr, new_service)?;
let handle =server.handle();

[seanmonstar]

Making use of a RefCell is probably not the way we want to go. I'm going to close this, but discussion should probably go on in #1075.