1.python协程（4）：asyncio
2.Vue3源码系列 (九)：异步组件 defineAsyncComponent 与 Suspense
3.Rust Async: smol源码分析-Executor篇
4.kotlin之协程(六),码解协程中的 async和launch的区别以及runBlocking
5.async-validator源码解析（二）：rule
6.c++基础语法之future，promise，码解async详细讲解-SurfaceFlinger学习必备c++知识

python协程（4）：asyncio

        asyncio是码解官方提供的协程的类库，从python3.4开始支持该模块

        async & awiat是码解python3.5中引入的关键字，使用async关键字可以将一个函数定义为协程函数，码解使用awiat关键字可以在遇到IO的码解买卖均价统计源码时候挂起当前协程（也就是任务），去执行其他协程。码解

        await + 可等待的码解对象（协程对象、Future对象、码解Task对象 -> IO等待）

        注意：在python3.4中是码解通过asyncio装饰器定义协程，在python3.8中已经移除了asyncio装饰器。码解

        事件循环，码解可以把他当做是码解一个while循环，这个while循环在周期性的码解运行并执行一些协程（任务），在特定条件下终止循环。码解

        loop = asyncio.get_event_loop()：生成一个事件循环

        loop.run_until_complete(任务)：将任务放到事件循环

        Tasks用于并发调度协程，通过asyncio.create_task(协程对象)的方式创建Task对象，这样可以让协程加入事件循环中等待被调度执行。除了使用 asyncio.create_task() 函数以外，还可以用低层级的 loop.create_task() 或 ensure_future() 函数。不建议手动实例化 Task 对象。

        本质上是将协程对象封装成task对象，并将协程立即加入事件循环，同时追踪协程的状态。

        注意：asyncio.create_task() 函数在 Python 3.7 中被加入。在 Python 3.7 之前，可以改用 asyncio.ensure_future() 函数。

        下面结合async & awiat、事件循环和Task看一个示例

        示例一：

        *注意：python 3.7以后增加了asyncio.run（协程对象），效果等同于loop = asyncio.get_event_loop()，loop.run_until_complete(协程对象)

*

        示例二：

        注意：asyncio.wait 源码内部会对列表中的每个协程执行ensure_future从而封装为Task对象，所以在和wait配合使用时task_list的值为[func(),func()] 也是可以的。

        示例三：

Vue3源码系列 (九)：异步组件 defineAsyncComponent 与 Suspense

       本文主要探讨Vue3源码中的gdal c#源码异步组件API，包括defineAsyncComponent与。

       defineAsyncComponent用于定义异步组件，接受一个异步函数loader或一个包含loader的对象options作为参数。当使用options时，可以自定义更多细节，如加载延迟、异常处理、备选组件和加载中渲染等。通过使用import()动态加载，loader常用来结合它引入单文件组件以构成异步组件。在函数内部，定义了一个load函数，它处理loader的异常，并验证加载成功的结果。返回值为一个经过defineComponent处理过的options对象，其中setup包含异步组件的渲染逻辑。

       在定义异步组件后，createInnerComp在加载成功时根据得到的resolvedComp创建内部组件，实际上通过createVNode来实现渲染，并继承外部组件的ref。

       Suspense在Vue3.2中引入，提供类似组件的API，用于处理异步组件的渲染和错误场景。当组件检测到__isSuspense为真时，调用process方法在渲染器内部渲染组件。根据旧节点状态，process选择挂载或更新节点。

       mountSuspense用于首次加载异步组件的挂载逻辑，而patchSuspense负责新旧节点的对比和更新。Suspense包含多个分支，如活跃、等待、mint+ui源码降级等状态，同时考虑异步依赖和降级状态。通过setActiveBranch设置活跃分支。

       SuspenseBoundary生成了一个Suspense实例，具备resolve、fallback、move、next、registerDep、unmount等方法。每个方法分别实现了解决异步结果、挂载降级内容、处理活跃分支和容器、递归取到活跃分支末端、注册依赖以及卸载SUSPENSE等核心功能。

       通过这些API的组合使用，Vue3实现了高效、灵活的异步组件加载机制，确保应用在处理复杂异步数据时依然保持流畅和响应性。

Rust Async: smol源码分析-Executor篇

       本文深入探讨了smol异步运行时中的Executor组件，尤其关注了Executor的实现细节。在smol的异步框架中，Executor扮演了核心角色，主要负责执行Future，并在多线程环境中调度和管理任务。

       Executor分为三种类型：ThreadLocalExecutor、Blocking Executor、Work Stealing Executor。ThreadLocalExecutor用于处理不能实现Send特性的Future，通过使用并发和非并发队列，减少了跨线程的同步开销。Blocking Executor则允许执行阻塞任务，lwip+源码分析并通过动态地开启线程来应对任务的增加，从而提高了资源的利用率。Work Stealing Executor则通过工作窃取的方式，实现了线程间的任务负载均衡，每个工作线程通过主动调用smol::run加入工作环境。

       在Executor的实现中，ThreadLocalExecutor通过线程局部变量来管理任务的生命周期，确保了任务与线程的绑定。Blocking Executor通过自适应地开启线程，以应对任务的增加或减少，从而保持了系统的高效运行。Work Stealing Executor通过工作窃取的方式，实现了任务在多个线程间的合理分配，提高了系统的整体性能。

       每一个Executor的实现都紧密围绕着任务的调度、执行和管理，通过不同策略满足了不同场景下的需求。ThreadLocalExecutor适用于无法实现Send特性的Future，Blocking Executor能够应对阻塞任务的执行，而Work Stealing Executor则通过动态负载均衡实现了任务的高效分配。

       在使用smol异步运行时时，需要注意到几个关键点。async_std的运行时采用了延迟实例化、按需自动启动的策略，简化了使用体验。然而，smol目前采用的是手动启用运行时的策略，可能导致运行时panic问题，用户需要额外的配置来启动整个工作窃取运行环境。因此，正确配置和启动smol运行时对于开发者来说是至关重要的。

       总结而言，java+源码+githubsmol的Executor组件设计精妙，通过不同类型的Executor满足了多样化的异步任务需求。其简洁而高效的设计，使得开发者能够轻松地将现有的库进行异步化处理，极大地提高了开发效率和系统性能。未来，随着smol的发展和完善，其在异步编程领域的应用将更加广泛。

kotlin之协程(六),协程中的 async和launch的区别以及runBlocking

       kotlin之协程(一),线程,进程,协程,协程可以替换线程吗?

        kotlin之协程(二),Kotlin协程是什么、挂起是什么、挂起的非阻塞式

        kotlin之协程(三),开始创建协程,launch,withContext

        kotlin之协程(四),协程的核心关键字suspend

        kotlin之协程(五),launch 函数以及协程的取消与超时

        kotlin之协程(七),协程中relay、yield 区别

        launch 函数定义：

        async 函数定义：

        从源码可以看出launch 和 async的唯一区别在于async的返回值

        async 返回的是 Deferred 类型，Deferred 继承自 Job 接口，Job有的它都有，增加了一个方法 await ，这个方法接收的是 async 闭包中返回的值，async 的特点是不会阻塞当前线程，但会阻塞所在协程，也就是挂起

        runBlocking 启动的协程任务会阻断当前线程，直到该协程执行结束。当协程执行结束之后，页面才会被显示出来。

        runBlocking 通常适用于单元测试的场景，而业务开发中不会用到这个函数

async-validator源码解析（二）：rule

       async-validator源码解析（二）深入探讨rule模块，解析其内部的校验逻辑和依赖工具函数。本文将逐步揭开rule目录的面纱，以及util.js中关键的format和isEmptyValue方法。

       rule目录的核心是export的一系列校验方法，它们接受value、source、errors和options作为参数。value是当前字段的值，source是整个待校验的对象，而errors数组用于存储验证结果。options允许自定义验证消息。每种规则方法如required、whitespace、range等，都有特定的验证功能，例如检查必填性、空白字符、数值范围等。

       format函数是个灵活的工具，根据传入参数的不同执行不同的格式化操作。而isEmptyValue则用于判断值是否为空，包括空字符串和空数组。

       在rule目录中，type.js规则尤其有趣，通过组合简单的判断，区分了值的多种类型，如整数、浮点数、数组等。

       后续文章将继续关注validator目录，完整揭示async-validator校验库的运作机制。点击github.com/MageeLin/asy.../analysis分支，探索每个文件的详细代码解析。

c++基础语法之future，promise，async详细讲解-SurfaceFlinger学习必备c++知识

       在SurfaceFlinger源码分析中，我遇到了一些新的C++基础语法，比如future和promise。这些工具的引入，使得在多线程环境中访问异步操作的结果变得更加方便。

       传统上，在C++中，我们需要通过创建线程并使用`join`等待线程完成，然后将结果赋值给变量。这种过程相对繁琐。为了解决这个问题，C++引入了`std::future`来访问异步操作的结果。`future`类不能立即获取结果，而是在异步操作完成后，通过同步等待或者查询状态来获取结果。`future`的状态有三种：未开始（`future_status::deferred`）、已完成（`future_status::ready`）、超时（`future_status::timeout`）。

       `std::async`函数用于创建异步任务，结果保存在`future`对象中。当需要获取异步结果时，通过`future.get()`方法来完成。如果只关注任务完成，可以使用`future.wait()`方法。`async`函数的参数包括线程创建策略（如`std::launch::async`、`std::launch::deferred`）、要执行的函数和函数执行时需要传递的参数。

       `std::promise`类帮助线程赋值。在线程函数中，通过`promise`对象的`set_value`方法为外部传递的`promise`赋值。在任务完成后，可以通过`promise`对象关联的`future`获取设置的值。

       在实际应用中，`promise`和`future`的结合使得在多线程环境下访问异步操作的结果更加灵活。例如，在SurfaceFlinger源码中，`future`用于等待子线程执行完成，并通过`set_value`设置结果，`get`方法用于获取结果。这种结合使得源码分析更加简便。

       为了深入理解这些新语法，我查阅了相关文档，并实践了在SurfaceFlinger源码中的应用。同时，我还使用了性能分析工具如`perfetto`和`systrace`来验证代码的运行效果。这些实践不仅帮助我学习了C++的新语法，还加深了对SurfaceFlinger源码的理解。

       如果你对这些C++基础语法感兴趣，或者想要了解SurfaceFlinger源码的详细分析，可以参考我的视频教程，或者私聊我进行深入探讨。我的文章和视频内容涵盖了C++基础语法的学习，以及如何将其应用于实际的SurfaceFlinger源码分析。

Async、Await 从源码层面解析其工作原理

       深入理解 Async 和 Await 的工作原理，往往需要从源码层面进行剖析。使用 Babel 进行转换后，可以清晰地发现 Async 和 Await 实际上借助了 switch-case 和 promise，实现对流程的控制。以一个使用 Async 和 Await 的函数为例，我们仅关注核心部分代码。

       经过 Babel 转换后的 name 函数，可以被拆分为三个主要部分：await 部分、return 部分以及 async 流程控制的结束部分（即 case "end"）。这个拆分使得流程控制变得更为直观。在流程控制中，每一步执行后，都会等待合适的时机进入下一次执行。

       这个“合适的时机”并非由 Async 内部决定，而是由执行的内容决定。例如，在发送异步请求后，只有在请求返回后才会进入下一个 case。

       为了实现流程控制，需要借助 regenerator-runtime 这个 generator、Async 函数的运行时。它负责将 name 函数进行包装，并添加流程控制所需的信息。如 _context，以及用于流程控制的关键 helper，如 _asyncToGenerator 和 asyncGeneratorStep。通过这些辅助工具，再在 regenerator-runtime 的基础上进行一层包装，最终得到一个可以执行的函数。这个函数实际执行时，会调用封装后的函数。

       在封装后的函数中，async1、async2 等实际上是在执行最终的封装函数内部的调用。这里的第三步是 Async 函数的核心机制。在 Promise.resolve(value).then(_next) 中，value 是每个分段最后的 case 返回的值。如果 value 是一个 Promise，那么在它 resolved 后，会将其.then添加到微任务队列。如果 value 不是一个 Promise，则直接添加，因为.then是一个微任务，当执行到它时，会调用_next，从而开始执行下一个 case。

       经过转换后的代码展示了封装后的函数内容，最终执行的是封装后的函数，因此说 async1、async2 执行实际上是执行封装后的函数。在封装后的函数内部，会调用 async1、async2。

async-validator源码解析（四）：Schema类

       async-validator源码解析（四）深入核心：Schema类详解

       在上篇中我们已经探讨了rule的细节，现在我们继续向上，关注async-validator库的基石——Schema类。尽管Schema类的代码较为复杂，但本文将从非核心的结构、属性和方法入手，同时在analysis分支的GitHub仓库中可以找到详细代码分析。

       Schema类是async-validator库的典型使用方式，其构造和功能强大。首先，我们从构造函数开始解析，它分为三个步骤，其中定义方法（define）暂且跳过，因为其代码量大，会在后续章节单独讨论。

       Schema类的构造函数涉及到messages.js中的defaultMessages，它提供了针对不同验证失败的模板提示。这允许用户在项目中根据需要定制错误提示。文档中提供了如何使用Schema.prototype.message方法自定义message的示例。

       然而，message的深度合并存在一个局限，只能处理两层嵌套，但默认messages正好满足这一需求。关于警告控制，官方文档建议在实例化Schema前通过warning方法进行设置，以控制警告信息的显示。

       此外，Schema类还提供了静态方法register，允许用户注册自定义的校验类型，尽管官方文档对此并未详述。这为开发者扩展库的功能提供了便利。