it’s… a bit hard to articulate clearly and probably i should try to write out some examples :)
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
it’s sort of the core insight of the futures design all over again: we only need one allocation
:shipit:
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
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.
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.)
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.
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
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.
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.
Ralith seems like the atomicity fundamentally needs to be pushed down to the db (in that example)
Ralith nothing in-process would serve
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.
in this case I mean parallelization in the sense of
future_a.join(future_b)
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
Even if it just ends up being
let x = await!(future_a.join(future_b));That does indeed satisfy the requirement.
I think something like that should work Soon™
.into_stream().flatten() appears to work, but kinda obtuse
NOTE: due to Gitter problems, this channel is deprecated in favor of #wg-net on https://discord.gg/rust-lang
@/all ^