I haven’t used Async-Await ever, so the following will probably be moot. But here I go:
I learned concurrency at Uni with C#. Most of it was meh/okay. The gist of it is this: - You have instances of Threads. Each one recieves a function to start in. When they return, they end. - Threads can be synchronized with “locks”. Basically, mutex. - Threads can be syncronized with Monitors (idk how they work, it was kinda cumbersome when I was taught). And finally, a golden nugget: - Threads can wait for signals/events. Signals are doors where threads wait for someone to open the door and let them keep going. Signals can be resat automatically (letting only one thread pass before locking again) or manually. Their design is pretty nice because they are a lot like single UI event-driven tools (from reactive programming). Everything else in C# threading at the time was pretty much meh. And error-prone, if you only used locks. But I think Signals were a golden nugget in a way. How would they fare in current multithreaded programming? Idk. I have to read a lot about the state of the art now. Thanks Chris for your manifesto. I’m reading it right now :)
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
