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

Tokio refactor: preserve ability to specify custom reactor #156

Open
theduke opened this issue Oct 4, 2018 · 2 comments
Open

Tokio refactor: preserve ability to specify custom reactor #156

theduke opened this issue Oct 4, 2018 · 2 comments

Comments

@theduke
Copy link
Contributor

theduke commented Oct 4, 2018

The 0.14 branch only allows creating a client with the global default reactor.

While this is fine for most use cases and is a nicer API, it should always be optionally possible to still specify the Reactor manually by passing in a Handle.

This came up quite a bit in the tokio refactor RFCs, I can dig out the issue if required.

But there should definitely be an additional method that still allows specifying the handle if you don't want to use the global default.

@theduke theduke changed the title Tokio refactor: preserve ability to use custom reactor Tokio refactor: preserve ability to specify custom reactor Oct 4, 2018
@freddyb
Copy link
Contributor

freddyb commented Jun 19, 2020

I'm running into a similar problem with a project of mine, where I'd like to reuse an existing actor across multiple consumers (e.g., rust-irc and hyper). Currently on the 0.13 branch, I start my irc clients first using a reactor from IrcReactor::new()and use that reactor's inner_handle() to then .spawn() my webserver on it.

Ideally, I'd like to retain the mechanism that creates a new reactor from within irc or consume a custom reactor when registering a client with a handler.

If you think this is useful to others, I'd try writing a pull request, but I think I'll need a bit of handholding. I don't know where to start :)

@aatxe
Copy link
Owner

aatxe commented Jun 24, 2020

Hi @freddyb, I believe the 0.14 update has already circumvented the need for that as it's more in line with the more modern approach in the newer versions of tokio. In particular, we no longer have an IRC reactor at all (instead using async/await and the default tokio executor most of the time).

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

No branches or pull requests

3 participants