Make crate independent of tokio runtime about stream-throttle HOT 6 CLOSED

@bekh6ex Thanks for the feedback! I agree it would be nice to remove the hard dependency on tokio. However I do feel trading tokio for futures-timer, is somewhat of a lateral move.

I did up a quick proof of concept (on the custom-timer branch), that lets you specify a closure via ThrottlePool::new(). The closure accepts a Duration, and returns a Future, so you can use any timer library you wish.

We could probably even do something with feature flags to make things more ergonomic. We could first rename ThrottlePool::new() to new_custom(). Then, if the tokio feature was enabled, we would provide a impl of new() which would not require the closure, and just work as before. Same could be done for the async-std equivalent.

What do you think of this?

from stream-throttle.

I think it might be useful to have a custom timer, but so far I cannot see a reason why one would need it if the default works. May be in no_std context...

My problem with tokio timer was that I was getting errors from ThrottlePool.queue() and thought that it is a normal behavior and I need to implement a backoff.

I would still suggest to go with futures-timer as a default option because it is a small single purpose thing. The only overhead is one extra thread per process.
And if you think that tokio is better default (BTW, why?) I would at least suggest to do something like .unwrap() when trying to sleep to make it In-your-face kind of an issue, because I don't see a valid runtime reason for this thing to fail except if the set up is incorect from the beginning and don't know how one can handle this error.

PS: So far I found it a bit annoying to work with libraries that depend on tokio because you always have to take care in which runtime certain piece of code will be executed, so I think decoupling from it will only do good for the end users.

from stream-throttle.

First I need to get things updated to use std::future::Future.

Once that is complete, it should be possible to make the custom-timer closure generic over the returned Future's Output type. That way you can have the both ThrottlePool::queue() and the Stream combinator resolve to a () (i.e. no error branch at all). The latest version of both futures_timer::Delay and tokio::time::Delay resolve to () (and panic), so this should work out exactly as you desire.

If I can figure out the feature flag stuff, there should be no need for a default timer at all. You would just indicate the one you want in your Cargo.toml. Supporting both futures-timer (which seems to be the async-std way, and tokio seems reasonable.

from stream-throttle.

@bekh6ex Would you mind giving this a try? https://github.com/mikecaines/stream-throttle/tree/custom-timer2 The readme was updated to mention the new feature flags, to support futures-timer.

from stream-throttle.

@mikecaines Works... 😄

from stream-throttle.

@bekh6ex Thanks! I published version 0.3

from stream-throttle.