green threads are fucking retarded
what about this thread
async await backed by a threadpool is better than goroutine trash
>async
>>109555114> this isn't about greentext threads
>>109555114>>109555129ok, no shit? it's a trade-off.greenthreads mimick the simplistic execution model everyone can understand.
>>109555611>greenthreads mimick the simplistic execution modelthats a bad thing
>>109557151it is today, but it was a necessary pain in the past.the fist jvms didn't support os level threadsand you had to rely on threads for anything that required preemptive multitasking.sure coroutines (cooperative multitasking) and async/await (to some extent) deliver better performances, but they're complex to implement and require your language to be built from the grounds up to properly support them.that's where green thread fit imo.
>>109555127This is a blue board but I like the look of Yotsuba A better.
>>109555114link?
>>109555114>but it is still a complete execution context. At a minimum, it must preserve register state, a call stack, and metadata used by the runtime schedulera goroutine also needs all these things
>>109557280You know what else fits?My dick, inside you
>>109555129hehehe.. i almost though that is some non-retard who made a proper statement, then, saw this..nope, you're retarded. it is the same threading model, OS threads just an extension of the "green" threads and parallelism in general is a subset of concurrency/asynchronicity.also these retarded black on white screencaps. write white on black next time
>>109555129>async await backed by a threadpool is better than goroutine trashthey are practically the same thingin both cases you have user space threads, that can be implemented using either cooperative yielding or preemption under the hood but that are preemptive as far the user is concerned, that do I/O in a way that doesn't block the kernel threadthe main difference is that goroutines block from the POV of the user and implicitly wait the results, while with async await the user has to await explicitly
>>109558409learn to read
finally people are waking up to the retardation of green threads.https://shardingdevnull.blog/posts/function-colors/
>>109558957a goroutine also needs all these things, use your brain
>>109559097you still can't read. he is describing goroutines you dumb fuck. async doesn't need any of these
>>109555114Always has been.State machines have always been superior to green threads.>But muh function coloring!!!!Literally not a problem in the real world. Especially not with languages that allow you to block while you wait.
>>109558978One thing I'm really happy about is that nowadays, developers have learned to appreciate good type systems. 10+ years ago everyone was raving about the "flexibility" of languages where variables and parameters could just be any type at runtime and freely switch between them. I guess that since them, developers had to maintain applications written in these languages by other developers and learned that knowing what kinds of parameters functions take and having a compile time warning is worth it.Just a shame that the biggest winner was TypeScript so modern applications are slow as shit.
>>109558978dumb ass blog posthe mixes together green threads, goroutines and fibers. They are different.when comparing async-await to green theads, the async attributes and function signature is a secondary concern. The main concern is how well does each concurrency primitve compose with concurrent code and with regular synchronous code.>Similarly, its common to see code in languages like go that doesn’t use concurrency where it could because it’s not obvious that the underlying calls perform IO.Ok, in other words it's a user issue.>One of the key advantages of async-await is that it gives you the future to combine with other futures.A future is merely a type system thing and doesn't intrisically gives you automatically an I/O multiplexing although with languages will generally have it. At the same time, languages without async and futures can have I/O mulitplexing. Go has it for example.>This allows you to turn your sequential code into more of a dependency map going from blocking location to blocking location minimizing the number of non-concurrency tasks with Promise.all (or Future::join or asyncio.gather depending on your language).Promise.any is the same thing as a bare I/O multiplexing call and Promise.all is trivial to implement.>While languages like go have similar mechanisms, they do not match the convenience of being able to await a list of futures, and for an arbitrary list you can be forced to build a giant pile of channels to try and handle successes vs failures or deal with trying to build your own result types.This is one of those cases where the dude pretends that function definitions don't exist. They do. Once written, the "problem" cease to exist.
>>109559602>Go you don’t have the flexibility of promises to either block on them or not, you always blockThat's true but if you don't have a polling primitive, not blocking won't give you any more flexibility concurrency wise. Creating futures in a loop and await them all is not that much different than creating goroutines in a loop and I/O multiplexing wait them.>sequential code isn’t necessarily that useful, what we actually want is a way to map dependencies between lines of codesequentical code CAN be useful and as for the dependence thing he's is talking about, either you have non-blocking I/O and you can do a multiplexed I/O wait later then code using the filehandles, either you have something like gorouintes that blocks but you still have the goroutines references as handles that you can multiplex wait for.>Function colors as a way of labeling functions in the type system>Async-Await is only one type of labeling we can do in this space,Function coloring is bad and we could label the promise value itself, no need to label the entire function which gives no benefit.>So if we consider the primary goal of async-await based concurrency to be marking functions that don’t block,How is that a goal? That's a negative and effect systems suck.>Similarly in high performance computing it can be helpful to know if code branches or loops, you could build a language where you cannot use for (or recursion) or if unless you explicitly mark the functionmental retardation
>>109559237>he is describing goroutines you dumb fuckI'm aware retard. He said that green threads has>a complete execution context. At a minimum, it must preserve register state, a call stack, and metadata used by the runtime schedulerI'm just saying that goroutines also needs all of those. What part of this is wrong? What part of this is hard to understand? Stop replying for saying nothing of value you inbred.>async doesn't need any of theseAnd? async wasn't mentioned anywhere in the text in the post I replied to you massive inbred faggot
>>109555221Lol.. what?
>>109559237>async doesn't need any of theseI concur. I/O multiplexing doesn't require many little stacks in the heap for the goroutine but goroutines can do more than I/O multiplexing, they can be also used to do do run code in parallel.Howver if you do need to process in parallel the results of those IO calls, with goroutines you don't have to use a work queue and a thread pool because the goroutines are already scheduled but you would need that with async.
stackful coroutines are betterenjoy your colored functions
Can someone explain like I'm a nigger
>async>stackful coroutines>functions of color>promises>green threadsReject modernity, embrace tradition.Callbacks and event loops allow you to avoid all this nonsense.
total async death
>>109559809there's literally nothing wrong with colored functions you crybaby faggots. it's just a marker that the function doesn't block the thread the same way you could introduce other markers like alloc to mark functions that allocate and then only functions that also have an alloc marker could call that function etc... it's a good thing
>>109555114Why? Please be concrete. Not ITS BAD IT"S JUST IS OK
>>109555129nobody uses intel cet
>>109562169Do any consumer-grade CPUs even have it?
I remember the C# team experimented with switching to green threads from async when green threads were the rage and they concluded that it's fucking trash and wrote a blogpost about it.
remember that the guy arguing for async await writes C# webapps which don't follow the rules and just block anyway because async/await makes for a terrible programming model (well yes, that's the point of having green threads)
>>109562623the conclusion was that it's too hard / confusing to support both, so they are doubling down on async / await and trying to make that less trash
>>109562623>The downside of async C# code is in that developers must decide which methods need to be async. It is not viable to simply make all methods in the program async. Async methods have lower performance, limitations on the type of operations that they can perform and async methods can only be called from other async methods . It makes the programming model complicated. What color is your function is a great description of this problem.>The key benefit of green threads is that it makes function colors disappear and simplifies the programming model. The green threads should be cheap enough to allow all code to be written as synchronous, without giving up on scalability and performance. Green threads have been proven to be a viable model in other programming environments.>We have chosen to place the green threads experiment on hold and instead keep improving the existing (async/await) model for developing asynchronous code in .NET. This decision is primarily due to concerns about introducing a new programming model.https://github.com/dotnet/runtimelab/issues/2398in other words: what we have is trash, other languages have something better, we are in too deep now and have to live with the trash we got
>>109562865explicit yielding is better than implicit, as with almost anything when writing code. They would want to have green threads because c# is popular enough for them to want it to cater to lowest common denominator which are hordes of pajeets spewing out garbage code. They don't want the programmer to have to think what he's doing, because he would have to have a slightest idea how shit works. The same reason why python and js are the most popular languages. What? Defining types? A type system? What even is a memory you're talking about? I don't know, I just copy paste stuff from react tutorial (claude copies it for me).
>>109563607green threads are a high level construct, just like garbage collection. you exchange some efficiency and control for robustness in large programs. async/await is a low level construct that gives the programmer more control but also more busywork that doesn't have anything to do with the problem they are trying to solve. rust has async/await because it's a low level language and control is paramount. js has it because they have no other choice because the languahe is single threaded. the c# devs simply got it wrong and can't change it now, they admitted it themselves. this is not a hill to die on anon, it's trash and arguing otherwise is like a c programmer arguing that header files are amazing technology
>>109555114>green threads are fucking retardedThere is a reason why Rust ditched them for stackless, polling async-await.
>>109559717You can have both. You can have multithreaded async without stacks.
>>109564233It's a real stretch to call the tooling around async/await low level in C#. Working with threads and mutexes sure that's low level but you really don't burn that much mental energy on the model C# went with.My biggest pet peeves with concurrency in C# atm is the conventions around passing around cancellationtokens and how really clunky it is to go from non coloured to coloured functions.I've been writing Go since 2012 as well and I wouldn't say a non coloured language is all that big a perk to have.Hopefully we get a full set of tooling for async await in C++ in 29.
>>109562865C# can call async functions from non async just fine. You just have to either ignore the result or poll or block waiting for the result.In languages with green threads, it's the same. Calling a blocking operation simply blocks the thread. You have to explicitly say "run this on a green thread" and you still have to somehow wait for or poll the readyness state of the result if the calling thread cares to receive a result without blocking itself.With explicit types - Task<Result> -(the "evil function color, aka, typing) it becomes obvious what is an IO function you most likely want to not block on.
go routines are so much nicer than dealing with await tranny garbage
>>109564233so what programming language should we use instead? java?>c++bloated that takes 5 years just to not make the 200 most common default mistakes>cbloated that takes 5 years just to not make the 200 most common default mistakesthere literally isnt anything else to use besides c# and java and java doesnt allow you memory control
>>109564305Idk what you mean chief, you need to be more explicit.
>>109564359>C# can call async functions from non async just finehere you have eric lippert telling you that this is bullshit and what you are doing rrsults in deadlocks : https://stackoverflow.com/a/45059862>You do not correctly block on async code. Blocking is wrong. Asking what the right way is to do the wrong thing is a non-starter.putting your fingers in your ears and ignoring the problem is not a solution. you are doing it because you don't want to deal with async/await. yes, that's the point of green threads where you can block and don't get deadlocks
>>109564343the model is not hard to understand but it is annoying to deal with, so much that one anon in this thread is ignoring how it works and blocks anyway, risking deadlocks. it is also annoying to structure your program around memory lifetimes, you'd much rather pay for gc than deal with the rust borrow checker for example. same story here>>109564414c# is a fine language otherwise, lots of features that java and go don't have. but pretending that async/await is not a mistake misplaced in a high level language is disingenous. it's allowed to have nuanced opinions, just because one aspect is retarded doesn't invalidate the rest. i prefer java because it's not as feature bloated, but either is fine
>>109559873threads r hard
>>109559641>a goroutine, for EXAMPLE (of a green thread)back2school
>>109559873green threads are like taking a slice of bread and spreading the ready-made pb&j on itasync state machines are like spreading and scraping the ready-made pb&j on the same slice of bread
>>109566625That stackoverflow answer is retarded. "Blocking on async code is wrong because... the second async operation will be scheduled to this thread" doesn't even make sense - if the current thread is running user code, and it chooses to block on the async operation, the thread isn't returned to the managed threadpool, so why would the second async operation be scheduled to run on it? Like if his argument is "the Task you're trying to block on may have synchronous continuations or have been scheduled with an explicit TaskScheduler that requires your thread to execute" - like a WinForms app or something, where the SynchronizationContext is used to ensure async callbacks execute on the UI thread - then sure, you'll deadlock. But just... don't fucking do that? Like, what, should I never use a synchronization primitive like a mutex because maybe I can write stupid code that deadlocks?If I have a synchronous method that wants to block on an asynchronous operation, it's unfortunate that the best solution is to tie up a thread owned by the managed pool - because now my operation is consuming two threads, once to do the asynchronous work and the other to wait for the work to complete - but to say "blocking is wrong" is silly. And if you know you don't need to restore the thread state when resuming from the operation, you could always call `.GetAwaiter().GetResult()` to avoid the extra thread.
>>109566888except that a goroutine is not a green thread
>>109567165the only distinction that you can make is that green threads were historically supported by a single real thread but that was never a necessity of green threads so goroutines and green threads are the same
>>109567215green threads block the kernel thread if they make synchronous calls, goroutines block from the POV of the user but since they used a non-blocking or asynchronous call under the hood they don't block the kernel threadgoroutines were originally and for a long time non-preemptive, while green thread are preemptive and even interruptible, directly without using an explicit channel
>>109567257implementation detail
>>109567279>>109567279>he needs LLM to understandbrainlet>green threads didn't inherently block the kernel threadI said for synchronous calls you stupid fuckI'm not readin the rest of that slop fuck you>implementation detailwrong, I've said it all already and I'm not going to repeat, you have already demonstrated to ignore crucial details
>>109567371a goroutine is just a green thread but rob gave it a different name because he is a gigantic faggot
>>109567444since Go 1.11, for the runtime it's the same thing but not for the user, because the user will only see blocking callsbut before that goroutines where cooperatively scheduled and were not preemptive
>>109567593>since Go 1.11rather 1.14 I thinkthis says 1.11https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.mdbut those say 1.14https://go.dev/doc/go1.14https://www.sobyte.net/post/2022-01/go-scheduling/
>>109567038eric lippert designed c#, you are doing it wrong and grasping at straws to justify your hacks because you don't want to accept that async / await is trash
>>109567038Your post is not marked async, nor is the entire reply chain it is part of; your argument is invalid.
>>109567926Appeal to authority; just because he's usually right, doesn't mean he's always right. I assume what he was really trying to say was "if you have to ask this question on stackoverflow, you don't understand enough about how async works in C# to reliably call those methods from a non-async method". Which is probably true, but doesn't mean that you can't do it safely and effectively. After all, it's not like async is magic - the compiler just transforms decorated methods into state machines on your behalf, so anything it can do you can do too.(I'm also not the guy you were arguing with before, I just got pissed off when I read that link because it's a shit answer that shouldn't be used to justify green threads)>>109568197What?
>>109568225>do it safely and effectivelyby making assumptions about implementation details. will the thread chosen for an asyc task be determined after you decided to block yours? you are relying on undefined behavior that could either break or if abused by enough people hinder the progress of the platform. yes the programming model sucks. certainly none of the performance advantages of async / await apply in this cursed "sometimes async sometimes blocking" fashion because you got the worst of everything, an operating system thread is wasted, stacktraces suck and async / await gunk is present everywhere, getting ignored when inconvenient
>>109569808At some point you have to accept that the method you're calling isn't going to do something retarded. Maybe it has methods that aren't re-entrant or something, or it's not thread-safe, or any number of "implementation details" that you just kind of have to accept. It's the same with async - if you know your application doesn't do X, you don't have to worry about something that breaks if X happens. Normally that's bad practice, but honestly with async in C# the language has been moving away from the scenarios where it breaks - ex. ASP.NET Core removed the synchronization context that Framework-based ASP.NET used, specifically because now with async it's easier to not have to reason about it.Stuff like stacktraces is an implementation detail of the CLR; in modern .NET (I think since like, 6?) an async method rolls up the stacktrace so you can see the continuation chain when you await it. And you can avoid blocking the OS thread as long as the underlying async operation actually yields the thread, which isn't your problem as the caller - if it didn't, it was going to tie up the threadpool thread anyway.Ultimately I don't disagree that it's generally a bad idea to call an async method from a non-async one. Modern C# applications generally declare their entry-point to be async, and then that propagates virally down the whole callstack, which introduces the overhead of the compiler-generated state machine for basically no reason. But honestly, in practice, I haven't found it to matter much. It probably varies by domain - if you're programming a game in Unity, you're probably more aware of trying to avoid async methods, vs. an I/O-bound HTTP server.
>>109570067that was a reasoned response, thank you. yeah, in practice the throughput of the typical business application is rarely limited by whatever threading scheme you use. i know this is just a trolling thread but some anons seem to genuinely believe that the async / await model is doing them any favors when in practice they are blocking os threads anyway. they would be much better served by a model where blocking is cheap, i.e. green / virtual threads, but they are unable to admit that c# goofed in that department for some reason
