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

refactor: Remove tokio dependency for blocking ureq and curl transports #422

Merged
merged 1 commit into from
Jan 31, 2022
Merged

refactor: Remove tokio dependency for blocking ureq and curl transports #422

merged 1 commit into from
Jan 31, 2022

Conversation

MarijnS95
Copy link
Contributor

These transport backends don't need the overhead of a tokio runtime and all the dependency crates that come with it, when they are already blocking on their own. A simple Rust thread and mpsc channel is enough. The transport thread implementation is duplicated between a tokio and non-tokio module that are used by reqwest/surf, and curl/ureq respectively.

See also #419 (comment) where this was briefly discussed.

TODO

  • Refactor this a bit to not duplicate the entire thing. Perhaps leave both implementations in the same file with some cfgs so that common changes are more easily shared. In the end the only difference is in the fn new() signature and the contents of the thread closure...
  • Figure out what to do with surf, which has been mentioned multiple times in not needing tokio?

These transport backends don't need the overhead of a tokio runtime and
all the dependency crates that come with it, when they are already
blocking on their own.  A simple Rust thread and mpsc channel is enough.
The transport thread implementation is duplicated between a tokio and
non-tokio module that are used by reqwest/surf, and curl/ureq
respectively.

See also
#419 (comment)
where this was briefly discussed.
Copy link
Member

@Swatinem Swatinem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the level of code duplication is acceptable, considering that the generics do not make it really possible to do conditional compilation.

@flub
Copy link
Contributor

flub commented Jan 28, 2022

  • Figure out what to do with surf, which has been mentioned multiple times in not needing tokio?

Don't worry too much about surf, certainly not in this PR. It's fine to leave this just about async/sync transports. The issue with surf is that is supports both async-std as well as tokio, so really the async version of the thread should have an implementations for both these runtimes.

@flub
Copy link
Contributor

flub commented Jan 28, 2022

thanks for this! I agree with @Swatinem that this is fine as is as well without further refactoring. so if you are fine with that as well we can merge as-is.

@MarijnS95
Copy link
Contributor Author

@flub yes please, all set for merging! It's probably already considered, but I'd love a new release with these changes 😬

@MarijnS95
Copy link
Contributor Author

An unrelated comment to this PR: When cloning all branches from this repo are adopted with it, though most appear to be stale remnants from closed PRs: https://github.com/getsentry/sentry-rust/branches/stale - would you mind deleting them for cleanliness?

@flub flub merged commit 9a41d6c into getsentry:master Jan 31, 2022
@MarijnS95 MarijnS95 deleted the no-tokio branch January 31, 2022 12:10
@flub
Copy link
Contributor

flub commented Jan 31, 2022

An unrelated comment to this PR: When cloning all branches from this repo are adopted with it, though most appear to be stale remnants from closed PRs: https://github.com/getsentry/sentry-rust/branches/stale - would you mind deleting them for cleanliness?

what happens to closed PRs when you delete their branch? do they keep giving useful info? seems a bit of lost history if they'd become useless.

I'm kind of used to having many useless branches in git, it's a side-effect of how git works and it doesn't cost much i think, they're mostly just a ref afaik.

@MarijnS95
Copy link
Contributor Author

MarijnS95 commented Jan 31, 2022

An unrelated comment to this PR: When cloning all branches from this repo are adopted with it, though most appear to be stale remnants from closed PRs: https://github.com/getsentry/sentry-rust/branches/stale - would you mind deleting them for cleanliness?

what happens to closed PRs when you delete their branch? do they keep giving useful info? seems a bit of lost history if they'd become useless.

History should still be accessible though the GitHub UI and fetchable from refs/pull/<id>/{head,merge}. If the branch with the same name is never pushed GitHub also offers a "restore" button on the PR, just in case. Note that some branches are 2-4 years old, I wonder how useful that still is :)

I'm kind of used to having many useless branches in git, it's a side-effect of how git works and it doesn't cost much i think, they're mostly just a ref afaik.

Branches are cheap but do cause the commits they reference to be downloaded too, in a non-shallow clone. It's not computing/storage cost as the changes are generally tiny, but the mental overhead in seeing a bunch of unused, "meaningless" branches lingering around. I'm more used to clean upstream repos and PRs from forks (every branch has meaning, such as "stable" branches for older tags), though gh pr create lately sure mixes that up more often than I'd like.

Fine to leave it as it is if that's your explicit preference, wasn't sure if these were left sitting around by accident.

@Swatinem
Copy link
Member

Most of those branches are mine ;-) And they contain a few ideas that I was kicking around very early, I would rather keep those if I ever come around to revisit that. But sure, some are also useless by now, but I don’t really want to look at each and every one in detail. I guess thats more of an argument to just get rid of them, but meh.

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.

3 participants