轻量级线程和通道优于 async/await 语法。

2作者: amano-kenji7 个月前原帖
# 轻量级线程和通道的优点 轻量级线程不需要操作系统线程的开销。你可以快速且廉价地启动大量轻量级线程。轻量级线程和操作系统线程可以通过通道进行通信。在进行IO/GPU密集型操作时,轻量级线程可以摆脱操作系统线程的束缚。 如果你通过通道在(轻量级)线程之间进行通信,你将获得同步编程的体验。没有函数的颜色(异步颜色 + 同步颜色)。 这个同步并发编程模型的良好例子包括goroutine、Clojure的core.async、JVM虚拟线程、Janet的fiber等。Clojure的core.async go块状态机不需要对运行时环境进行修改。 # 轻量级线程和通道的缺点 同步并发有一些权衡。我读到内置轻量级线程所需的更改可能会使其他语言通过FFI(外部函数接口)与受影响的语言交互变得困难。我怀疑这可以通过未来的研究来克服? 错误无法在线程外传播,因此你必须在线程中处理错误,或者将错误值传递给其他线程。Go语言以没有异常而闻名。Go只有类似于内存溢出错误的恐慌(panic)。 # async/await语法的优点 除非你想像在C语言中那样定期轮询,否则async/await语法不需要对运行时环境进行更改,这使得其他语言通过FFI与受影响的语言交互变得更加容易。 然而,core.async的go块是基于宏的状态机,虽然基于宏的状态机需要一些注意,但它们不需要对运行时环境进行更改。 # async/await语法的缺点 Async和await是具有传染性的。任何接触到async代码的内容都会变成async。 # 我的比较 在隔离线程中处理异常并将错误值传递给其他线程,比起具有传染性的async/await语法要更好。在(轻量级)线程和通道中处理错误会变得有些繁琐,但在每个隔离线程中尽早处理异常可以减少未处理异常导致程序崩溃的可能性。
查看原文
# The pros of lightweight threads and channels<p>Lightweight threads don&#x27;t have the cost of OS threads. You can launch a lot of them cheaply fast. Lightweight threads and OS threads can communicate with each other via channels. Lightweight threads can be freed from OS threads during IO&#x2F;GPU-bound operations.<p>If you communicate between (lightweight) threads via channels, you get synchronous coding experience. There is no function color(async color + sync color).<p>Good examples of this synchronous concurrenct programming model are goroutine, clojure core.async, JVM virtual thread, janet fiber, and so on. Clojure core.async go block state machine doesn&#x27;t require changes to runtime environment.<p># The cons of lightweight threads and channels<p>Synchronous concurrency has a few trade-offs. I read that the changes required for built-in lightweight threads may make it difficult for other languages to interact with the affected language via FFI(foreign function interface). I suspect this can be overcome with future research?<p>Errors cannot be propagated outside threads, so you have to take care of errors in threads or pass error values to other threads. Go is famous for not having exceptions. Go only has panics like out-of-memory errors.<p># The pros of async&#x2F;await syntax<p>Unless you want to poll regularly as you would in C language, async&#x2F;await syntax doesn&#x27;t require runtime environment changes that make it difficult for other languages to interact with the affected language via FFI.<p>However, core.async go blocks are macro-based state machines which don&#x27;t require changes to runtime environment although macro-based state machines require some care.<p># The cons of async&#x2F;await syntax<p>Async and await are contagious. Whatever touches async code becomes async.<p># My comparison<p>Handling exceptions in isolated threads and passing error values to other threads is better than contagious async&#x2F;await syntax. Error handling becomes a bit tedious with (lightweight) threads and channels, but handling exceptions as early as possible in each isolated thread reduces the possibility that unhandled exceptions crash the program.