by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 07 2018 13:58
    @tobz banned @SoniEx2
  • Aug 01 2018 23:32

    carllerche on gh-pages

    Documentation for tokio-rs/toki… (compare)

  • Aug 01 2018 23:29

    carllerche on master

    Deprecate tokio-proto. (#209) (compare)

  • Aug 01 2018 23:29
    carllerche closed #209
  • Aug 01 2018 19:10
    tobz commented #207
  • Aug 01 2018 19:08
    tobz synchronize #209
  • Aug 01 2018 19:00
    tobz commented #209
  • Aug 01 2018 19:00
    tobz opened #209
  • Jul 26 2018 14:13
    upsuper opened #208
  • Jul 20 2018 03:16
    driftluo edited #207
  • Jul 20 2018 03:15
    driftluo opened #207
  • Jun 15 2018 13:04
    ignatenkobrain opened #206
  • Jun 12 2018 01:41
    rphmeier commented #205
  • Jun 12 2018 01:41
    rphmeier edited #205
  • Jun 12 2018 01:40
    rphmeier commented #205
  • Jun 12 2018 01:40
    rphmeier closed #205
  • Jun 12 2018 01:40
    rphmeier commented #205
  • Jun 12 2018 01:40
    rphmeier commented #205
  • Jun 12 2018 01:36
    rphmeier opened #205
  • Jun 01 2018 13:55
    flosse commented #202
Ash
@ashthespy
as this stage yes..
But I am guessing that that when this was written initially, that was the best option..
Ash
@ashthespy
After a bit more playing around, I don't see how to pass this closure to spawn_local
    pub fn spawn<F, R>(&self, f: F)
    where
        F: FnOnce(&Handle) -> R + Send + 'static,
        R: Future<Item = (), Error = ()>,
    {
        // use futures::future::lazy;

        let mut te = current_thread::TaskExecutor::current();
        let spawn_res = te.spawn_local(Box::new(f));

        // This fails when called from a differnt thread
        // let spawn_res = current_thread::spawn(f);

        // This fails when the Future doesn't implement Send
        // let spawn_res = self.0.handle.spawn(f);

        match spawn_res {
            Ok(_) => (),
            Err(e) => error!("Session SpawnErr {:?}", e),
        }
    }
error[E0277]: the trait bound `F: futures::Future` is not satisfied
   --> core\src\session.rs:161:40
    |
156 |         R: Future<Item = (), Error = ()>,
    |                                              - help: consider further restricting type parameter `F`: `, F: futures::Future`
...
161 |         let spawn_res = te.spawn_local(Box::new(f));
    |                                        ^^^^^^^^^^^ the trait `futures::Future` is not implemented for `F`
    |
    = note: required for the cast to the object type `dyn futures::Future<Error = (), Item = ()>`
Ash
@ashthespy
hmm I give up for now, will quit spamming here and consolidate and post for help elsewhere :-) Thanks @tanriol for you inputs! :-)
matrixbot
@matrixbot
tanriol Ash (Gitter): The following signature almost compiles for me - except for the fact there's no handle in Self at the moment
    pub fn spawn<F, R>(&self, f: F)
    where
        F: FnOnce() -> R + Send + 'static,
        R: Future<Item = (), Error = ()> + 'static,
    {
        use futures::future;
        self.handle.spawn(future::lazy(|| f()));
    }
Ash
@ashthespy
@tanriol got it to compile after the hint to call the closure, thanks! :-)
Ash
@ashthespy
FWIW, I figured out how to get our project ported to tokio 0.1 with some help
brockelmore
@brockelmore
can anyone point to an example of a minimal implemetation of accepting a post with json?
Bartosz Sypytkowski
@Horusiath
Hi, could anyone point me to some info on how to use tokio TcpStreamto perform non-blocking read with await syntax?
matrixbot
@matrixbot
tanriol Bartosz Sypytkowski (Gitter): See AsyncReadExt docs
Bartosz Sypytkowski
@Horusiath
thx @matrixbot
aohan237
@aohan237
why async fn is not send? how to solve it?
future cannot be sent between threads safely: future returned by refresh_loop is not Send
async fn refresh_loop() {
let mut time_delay = None;
loop {
time_delay = token_client(time_delay).await
}
}
just like this
``````
async fn refresh_loop() {
    let mut time_delay = None;
    loop {
        time_delay = token_client(time_delay).await
    }
}
i just want a token refresher run infinitely
but when tokio::spawn it shows not Send
what's problem
Bartosz Sypytkowski
@Horusiath
is is possible to have concurrent read/write on TcpStream? tokio::io::split is not an option because ReadHalf/WriteHalf have lifetime specifiers (I need to use them from two different concurrently running tasks). I've read #1108 and followed on linked PRs, but the proposed code won't work with the current version of tokio.
matrixbot
@matrixbot
tanriol Bartosz Sypytkowski (Gitter): IIRC, tokio::io::split should be an option as it does not introduce lifetimes on ReadHalf/WriteHalf, unlike TcpStream::split. Are you sure you're looking at the correct one?
Bartosz Sypytkowski
@Horusiath
thx, my mistake - I initially meants TcpStream split, but accidentally I answered my own question. Another question: is there any way to make tokio RwLock upgradable? Case - a RwLock<HashMap<A, B>>, which originally is taken for read access to get some element, but if it doesn't exists, upgrade to write lock, create the element and insert it into map.
Qihe Bian
@ufosky
What is the difference between tokio::runtime::Runtime::spawn() and tokio::runtime::Runtime::handle().spawn()?
Joonas Koivunen
@koivunej
@Horusiath I haven't found many upgradeable rwlock implementations in general. I think that's because of rwlock being surpringly costly in general, and the upgrade protocol would even further raise this cost. I'd go with plain Mutex for the time being, but you might know more about your performance reqs than I do :)
Joonas Koivunen
@koivunej
@ufosky I might be wrong, but the latter one (Handle::spawn) is a reminiscent of the tokio 0.1 api which got turned into tokio::task::spawn in tokio 0.2
Joonas Koivunen
@koivunej
@aohan237 from the code you pasted I'd think the value from token_client(...) is not Send; you can check this if you add a function: fn check_sync<T: Send>(_: T) {} and call it check_sync(token_client(None)) -- if the token_client is not Send you should get an error from typecheck when you run cargo check
aohan237
@aohan237
@koivunej thanks. the reason is i use actix::client as a http client ,and it is not Send.
Joonas Koivunen
@koivunej
@aohan237 ok, hopefully you can find help with that more specific problem easier! for future reference, I think tokio has a way to execute non-send futures as well but I have no experience with them: https://docs.rs/tokio/0.2.16/tokio/task/struct.LocalSet.html
matrixbot
@matrixbot
Ekleog Hey! Is there an example somewhere of using tokio for semaphores or unix pipes? I'm basically looking for a way to do cross-process notification
Ekleog I'd assume that tokio's File probably can do it, but if there's an example… :)
michael
@iptq
any way i can get tokio::fs::File to also be a futures::io::AsyncRead...
seems like the same trait exists in both libs
and they're not compatible with each other
nbvm, asking in discord
Michal 'vorner' Vaner
@vorner
I don't know if there's a ready-made solution, but it might be quite easy to set up a compat wrapper. Eg. a newtype and do impl<T: tokio::AsyncRead> futures::AsyncRead for CompatWrap(T) { .. }. They seem to have differend provided methods, but the only required method looks the same.
Maybe someone already did that and there's a crate out there.
Alistair A. Israel
@aisrael
Hi, channel! I must be missing something obvious, but am trying to use tokio without the async stuff and can't figure out how to block for/await the result of another future within a future/closure that's already passed to the runtime
Michal 'vorner' Vaner
@vorner
There are methods on the runtime to block on specific future or for it to run until all the spawned futures are done
Alistair A. Israel
@aisrael
Thanks, but I also keep running into the lifetimes thing. So... do I just create a single move closure and pass the runtime into that, then block_on or spawn tasks inside? Sorry, it's really not obvious. Yes, I know async / await takes a lot of that pain away but am trying to figure this out from ground up (and maybe write an article on it)
I mean, this works but I don't know what to put in line 5
    let mut rt = Runtime::new().unwrap();
    rt.block_on(futures::future::lazy(|_| {
        println!("in block_on");
        let f = returns_immediate_future();
        // what to put here to block and wait for the result of `f`?
    }));
matrixbot
@matrixbot
tanriol Without async/await you cannot really "block and wait for the result"... well, you can, but it would occupy the whole thread. The proper way without async/await would be to either write a poll-based future implementation, or string together your future from many small closures with future combinators.
Alistair A. Israel
@aisrael
Something like rt.spawn(f).and_then(...)? I can't get that to even compile :(
Michal 'vorner' Vaner
@vorner
By using spawn, you give the future up. Like, for good. It lives its own life now. You need to do and_then and others on it before spawning, to build a bigger future and spawn the result.
Alistair A. Israel
@aisrael
Thanks. I've been trying that but in futures 0.3.4 the Future trait doesn't seem to have an and_then, so, am stumped. Unless am missing another trait to use?
Alistair A. Israel
@aisrael
Ok, I think I got it
Alistair A. Israel
@aisrael
Is tokio::runtime::Runtime.enter() guaranteed to run the given block to completion, like .block_on()? I assume it is, it’s just that the documentation doesn’t explicitly state so.
prassee
@prassee
Is there any actor based frame work written based on Tokio