People
Activity
    Aaron Turon
    @aturon
    Replied, hopefully that helps
    it’s… a bit hard to articulate clearly and probably i should try to write out some examples :)
    Tyler Mandry
    @tmandry
    yeah, I think I know what you mean. that's why you said "in the context of an async block" in the original post, but wasn't sure
    Aaron Turon
    @aturon
    it sort of feels… too simple to be true :)
    Tyler Mandry
    @tmandry
    exactly
    some examples would probably help
    but very cool :grinning:
    so effectively what the async block is doing is creating a struct with our pinned async state and our combinator side-by-side. The combinator operates happily on a PinMut reference
    Aaron Turon
    @aturon
    yes precisely
    it’s sort of the core insight of the futures design all over again: we only need one allocation
    Tyler Mandry
    @tmandry
    yes!
    Aaron Turon
    @aturon
    @tmandry an example, https://github.com/rust-lang/rfcs/pull/2418#issuecomment-389395951
    Tyler Mandry
    @tmandry
    and the PinMut isn't actually created until the async block is polled, so it can move around prior to that
    :shipit:
    Benjamin Ylvisaker
    @benjaminy
    I reached out to Alex Crichton for feedback on a research project I have been working on related to async/await, cooperative concurrency and atomicity. He said he wasn't working on that much any more and suggested I contact the Net WG. I don't know if this is on-topic in this room, but if it sounds interesting, feel free to contact me at bylvisaker@coloradocollege.edu
    matrixbot
    @matrixbot
    Ralith could you maybe talk a little about what the project is?
    Benjamin Ylvisaker
    @benjaminy
    The overall theme is atomicity in cooperative concurrency frameworks like event loops, coroutines, async functions, etc. I gathered event traces from popular web applications and show that risky patterns (very short interruptible chains of events) are common. Then I look into the design, semantics and efficiency of adding an atomic block to JavaScript and a C dialect with cooperative threads.
    Aaron Turon
    @aturon
    @seanmonstar congrats!
    Stefan Junker
    @steveeJ
    @benjaminy can you tell something about the context of the research project?
    Sean McArthur
    @seanmonstar
    @aturon: thanks :D
    Benjamin Ylvisaker
    @benjaminy
    Hmm... I'm not sure what context you're interested in. After grad school I worked for a few years at a company that makes static analysis tools. My main role was working on the concurrency bug checkers. I became more and more convinced that there had to be a better way to do multitasking. Then I left that job and am now faculty at a teaching-focused college. There is not much of a research community where I work, so I have to reach out to find people who might be interested in my project. (As a fun bit of trivia: My understanding is that Rust was influenced to some extent by Cyclone. Dan Grossman was a partial advisor to me in grad school.)
    matrixbot
    @matrixbot
    Ralith I'm kind of curious what you mean by "risky patterns"
    Benjamin Ylvisaker
    @benjaminy
    The starting point for "risky patterns" is very short chains of continuations. That is, sequences of causally-linked callbacks where the whole sequence takes a small amount of time. There is some chance that such chains could be interrupted, causing an atomicity bug. I go into a little more detail in my draft, which I'd be happy to email to anyone.
    matrixbot
    @matrixbot
    Ralith the presumption that chains of operations entail an ad-hoc and unenforced atomicity requirement seems strange to me
    Ralith maybe I'm weird, but when I write a chain of futures, failure at any point is expected and accounted for, generally by propagating an error upwards, which is what the combinators make easy
    Benjamin Ylvisaker
    @benjaminy
    Short chains of futures/promises/whatever do not immediately imply a bug, for sure. It has become increasingly common in at least the JS ecosystem to define library functions as async, even when they complete very quickly in most calling contexts. I'm exploring async blocks as an easy way to avoid atomicity problems in such cases.
    matrixbot
    @matrixbot
    Ralith what're some concrete examples of atomicity problems you've identified that this might address?
    Benjamin Ylvisaker
    @benjaminy
    This paper has some good examples: http://www.tcse.cn/~wsdou/papers/2017-ase-nodecb.pdf In particular, figure 4 shows an atomicity violation from a real bug database. The developers fixed it by replacing two DB API calls with a single atomic one. But of course that maneuver isn't always possible. And it would be simpler to wrap the whole thing in an atomic block.
    matrixbot
    @matrixbot
    Ralith maybe I'm missing something, but wouldn't that bug still exist in the presence of multiple processes, which is the typical deployment model of that type of service?
    Ralith seems like the atomicity fundamentally needs to be pushed down to the db (in that example)
    Ralith nothing in-process would serve
    Benjamin Ylvisaker
    @benjaminy
    Yes, multiple processes would require the atomicity be enforced in-DB in that example. I'm focused on situations where local multitasking is the issue. For example, imagine a similar scenario where the DB involved is the browser local storage and the only relevant concurrency is multiple local event/future/promise chains.
    Yoshua Wuyts
    @yoshuawuyts
    hey, I was wondering: has there been any talks about parallelization in control flow using async/await?
    in this case I mean parallelization in the sense of future_a.join(future_b)
    Yoshua Wuyts
    @yoshuawuyts
    haha, I'm probably being vague here. I'm mostly approaching this from JS, where it's trivial to define a stream or event emitter inline and carry on like it's nothing. Warranted error handling isn't great there - but I was wondering if there's been any discussion about this at all haha
    Jay Oster
    @parasyte
    Rust needs parallel execution built into async/await if it is going to be competitive in network services. I don't know of any explicit discussions around that, but it's one of those "so obvious it probably won't be mentioned directly" sort of things.

    Even if it just ends up being

    let x = await!(future_a.join(future_b));

    That does indeed satisfy the requirement.

    Jay Oster
    @parasyte
    Not much different from the JavaScript world:
    let x = await Promise.all([promise_a, promise_b]);
    Aaron Weiss
    @aatxe
    @parasyte there's also futures::future::join_all
    Jay Oster
    @parasyte
    :+1:
    Aaron Weiss
    @aatxe
    let x = await futures::future::join_all([future_a, future_b]);
    I think something like that should work Soon™
    Jay Oster
    @parasyte
    That's what I meant by the "obvious" quote. Sounds just fine to me.
    Yoshua Wuyts
    @yoshuawuyts
    aatxe: oh awesome, didn't know about join_all :D
    Dan Burkert
    @danburkert
    Is there a built in combinator to flatten a stream nested in a future to just a stream?
    .into_stream().flatten() appears to work, but kinda obtuse
    Dan Burkert
    @danburkert
    ah, .flatten_stream()
    Sean McArthur
    @seanmonstar
    @aturon @cramertj: i tried in the #futures channel; could futures 0.2 be yanked? rust-lang-nursery/futures-rs#1039
    Aaron Turon
    @aturon

    NOTE: due to Gitter problems, this channel is deprecated in favor of #wg-net on https://discord.gg/rust-lang

    @/all ^