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 Time vs Core Time for query.wait() #70

Closed
bcpeinhardt opened this issue Oct 1, 2021 · 2 comments
Closed

Tokio Time vs Core Time for query.wait() #70

bcpeinhardt opened this issue Oct 1, 2021 · 2 comments

Comments

@bcpeinhardt
Copy link
Contributor

The wait method on query is documented as taking core::time::Duration. Can I / should I use the tokio::time::Duration here, and what are the effects in terms of yielding a thread vs. blocking (I would like to avoid blocking). Sorry I'm still wrapping my head around async w/Tokio.

@stevepryde
Copy link
Owner

The waiting via Tokio isn't a blocking call so don't worry about that aspect. Yes that particular call will wait but other Async operations can still happen concurrently.

I don't remember which duration it wants off the top of my head but I think it should accept either.

@stevepryde
Copy link
Owner

I just checked and Tokio uses core::time::Duration anyway (and std::time::Duration is also just the same one).

Have a read of the async book for more details on blocking vs non-blocking in an async context: https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html

There are no blocking operations in thirtyfour so don't worry about that aspect so much when trying to automate a browser. If you call .await after each call then things will run in series anyway. If you need to run things in parallel, use Tokio's join! or select! macros. This is explained fairly well in the async book here: https://rust-lang.github.io/async-book/06_multiple_futures/01_chapter.html

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

No branches or pull requests

2 participants