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

executor: move into tokio crate #1702

Merged
merged 11 commits into from
Oct 29, 2019
Merged

executor: move into tokio crate #1702

merged 11 commits into from
Oct 29, 2019

Conversation

carllerche
Copy link
Member

A step towards collapsing Tokio sub crates into a single tokio
crate (#1318).

The executor implementation is now provided by the main tokio crate.
Functionality can be opted out of by using the various net related
feature flags.

A step towards collapsing Tokio sub crates into a single `tokio`
crate (#1318).

The executor implementation is now provided by the main `tokio` crate.
Functionality can be opted out of by using the various net related
feature flags.
tokio/src/fs/mod.rs Outdated Show resolved Hide resolved
tokio/src/fs/mod.rs Outdated Show resolved Hide resolved
tokio/src/lib.rs Outdated Show resolved Hide resolved
tokio/src/runtime/mod.rs Outdated Show resolved Hide resolved
@hawkw
Copy link
Member

hawkw commented Oct 28, 2019

Looks like this needs to be rebased, since #1625 made a bunch of conflicting changes.

@carllerche carllerche merged commit c62ef2d into master Oct 29, 2019
@carllerche carllerche deleted the collapse-exec branch October 30, 2019 03:31
@najamelan
Copy link
Contributor

I was using the tokio-executor crate directly, to avoid bloating dependencies. It looks like currently the only way to get the functionality back is to enable the "rt-full" feature.

There are many reasons not to want to pull all of this in. Maybe a library just wants to implement traits Executor and TypedExecutor without even pulling in an impl, maybe one writes an application which does FS access, but no networking, maybe one wants to use the Actor model as a software design model and do async even without IO, etc...

Would it be possible to design the features so as to be able to enable things bottom up, eg. not pulling anything not needed at each step?

Slightly off topic: Other recent changes have made tokio harder to use flexibly. eg. Networking types will no longer work when not within a runtime (before it was possible to use the networking primitives and spawn their futures on a non-tokio executor).

It's unfortunate that the reasoning is package-deal like. I am very reluctant to use frameworks like this, even though I feel tokio has an excellent executor implementation. It's all good when writing a small app, but when writing libraries that shall be used by others, there's no way to justify forcing the package deal on downstream users.

@taiki-e
Copy link
Member

taiki-e commented Oct 30, 2019

@najamelan FYI: Once #1695 is merged, it should be able to use traits without depending on the runtime: https://github.com/tokio-rs/tokio/pull/1695/files#diff-66fb4a030b180360b997fa738670656fR124-R125

@najamelan
Copy link
Contributor

@taiki-e Thanks, so I see there will be executor-core. Will it be possible to use the 2 executor impls that existed in tokio-executor without pulling reactor/timer/network?

@carllerche
Copy link
Member Author

@najamelan thanks for the heads up. The state if things is not final. The plan will be to enable the ability to get fine grained access to the various components using feature flags.

Collapsing crates is just the first step.

Could you open a new issue so we are sure to cover your use case?

@najamelan
Copy link
Contributor

@carllerche Ok, thanks will open an issue.

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

Successfully merging this pull request may close these issues.

6 participants