Ask the real poster/dev in one of the lemmy.ml communities.
Fundamentally the issue is that Future is a n+m model where you have n virtual threads executing on m OS threads. As such traditional solutions to associating data to OS threads like thread locals don’t work as there’s no guarantee that a given virtual thread will continue to execute on any given OS thread.
This is fully runtime/platform dependant and not true in many cases. Not only strictly single-thread runtimes exist, but async is already used in places like the embedded world where there is no OS for there to be OS threads, single or otherwise.
It is for this reason that the extra trait bounds on the implicit impl Future return type in async functions have caused a lot of trouble (implicit Send, ...etc). If for nothing else, adding context to the equation would make that situation more complex.
In any case, attaching "metadata" to T: Future data (instead of the runtime or some other global context) doesn't make any sense in my head, as one would be "await"ing around and the concrete return type is often hidden behind that impl Future. And if the data is really special and needs to be attached to T: Future, then it's (conceptually) just data that is a part of T, not Future.
FutureExt trait methods return a wrapper struct WithContext which is where the data (T) and the context are stored. One method takes context directly from an argument, the other clones one from a thread local. Data can't hang in thin air to be attached to a triat. This also shows that the abstraction you (presumably) were asking about is both possible and already exists.T: Future types would make the abstraction non-zero-cost in any case.It's not about magic, it's just not how the abstraction works.
Let's have a concrete example, poem::web::Data utilizes opentelemetry::context::FutureExt which has the trait methods with_context() and with_current_context(). But where is the data/context actually stored? In the WithContext struct of course. Because there is no such a thing as pinning (meta)data to a trait.
struct SomeFuture;
impl Future for SomeFuture {
// ....
}
where are you going to "pin metadata"?
Stating the obvious: a trait is type class you implement for types. It's not something you can "pin metadata" (or any data) to.
Not sure if you're talking about the language, or the core/alloc/std libraries, or both/something in-between?
Can you provide specific examples, an which specific languages are you comparing against?
What serious Linux users buy GPUs based on raw gaming performance on release week?
I personally buy based on open-source driver support. And this includes long-term active support, AND developer approachability.
My current GPU is an AMD/Radeon one because of that. But I'm reconsidering my position when my next hardware upgrade comes.
I reported an AMD GPU driver issue to mesa once. It was tested, confirmed, and patched by a competent AMD developer within a few days. Now you have easily reproducible issues like this not even going past the testing phase after many months. And there are similar issues across all model generations.
If I were to upgrade my workstation next year, I would probably go with an AMD CPU and an Intel GPU, which is the exact opposite of my current setup 🙃. One should never rely on outdated perceptions.
A reminder that the Servo project has resumed active development since the start of 2023, and is making good progress every month.
If you're looking for a serious in-progress effort to create a new open, safe, performant, independent, and fully-featured web engine, that's the one you should be keeping an eye on.
It won't be easy trying to catch up to continuously evolving and changing web standards, but that's the only effort with a chance.
Examples ARE usage documentation.
What value is this blog supposed to be adding exactly?
The fact that top-level and API descriptive explanations are important?
The fact that some projects don't have complete documentation?
To whom exactly would this be considered new information?
What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian
[closes tab]
Maybe I missed it, but you don't seem to mention anywhere sub-file sync (binary diffing) support (or presumably the lack of it), which is very important for fast syncing when files actually change!