haj*_*ime 5 multithreading asynchronous reactive-programming
现在每个人似乎都在谈论Reactive应用程序,而Reactive manifesto似乎鼓励非阻塞/异步代码.我在youtube上看过很多视频,其中扬声器鼓励非阻塞代码但是没有人说除了说阻止之外写阻塞代码而不是阻塞代码的好处
"using futures is good because it is not blocking your code" - some speaker
这只是让" 阻塞代码 "听起来像一个坏词.
我的问题很简单:如果我有一个任务,我运行它:
事实是,在上述两种情况下,我想要运行的实际任务总是在1个线程上运行.第二个选项只会增加应用程序的复杂性,第一个选项更简单,可能更快,因为我不需要委托.
我理解在执行任务期间的某个时刻,需要执行多个并发任务,因此线程/非阻塞/异步代码在这里有所帮助.但是为什么Reactive宣言鼓励非阻塞应用程序被激活？除了应用程序中的一大堆Futures和Promise之外,还有什么好处,这使得代码更复杂,更难调试？
非阻塞代码 - 一个线程将任务委托给另一个线程
事实并非如此.非阻塞IO有各种形式,但通常在IO运行时没有阻塞线程.IO完成后调用回调.
这就是为什么非阻塞/异步IO很难使用的原因.它将您的代码转换为回调.
非阻塞/异步IO的两个好处:需要更少的线程和更少的上下文切换.在某些情况下,它可以使用交互式GUI更容易编程.
非阻塞/异步IO当然不应该是默认选择,因为它会导致生产力下降.
我已经在.NET上下文中写了两个标准部分,我将链接到:https://stackoverflow.com/a/25087273/122718为什么EF 6教程使用异步调用？ /sf/answers/895769801/默认情况下我们应该切换到使用异步I/O吗？
概念应该延续到大多数平台.
| 归档时间： |
|
| 查看次数： |
900 次 |
| 最近记录： |