一、概述
Shell 调用 FFmpeg 进行定时启动和停止录制。
曾好几次尝试在 Hexo 中使用 hexo-math
、hexo-renderer-markdown-it-plus
等包以支持 LaTeX 皆不成功,要么不行要么错乱。刚刚了解到如果使用 NexT
主题的话则不需要手工安装任何包。本文是一篇备忘录。
hexo: 7.0.0
hexo-theme-next: 7.8.0
在 ASP.NET
或 ASP.NET Core
中,如果服务端得到一个 JSON
字符串(比如从 Redis 缓存中获取),我们可以通过 Content
方法或直接创建 ContentResult
对象来作为 Action
的返回值。
1 | var json = "{\"key\": \"value\"}"; |
1 | return new ContentResult |
而在 SignalR
中,在 ASP.NET Core 7.0 之前,对于一个 JSON 字符串只能先反序列化,否则 Web 前端得用 JSON.parse()
处理一次。
本文主要记录测试 RawResult
的结果。
PUT
和PATCH
方法用于更新现有资源。 它们之间的区别是,PUT 会替换整个资源,而 PATCH 仅指定更改。
在 ASP.NET Core Web API 中,由于 C# 是一种静态语言(dynamic
在此不表),当我们定义了一个类型用于接收 HTTP Patch 请求参数的时候,在 Action
中无法直接从实例中得知客户端提供了哪些参数。
比如定义一个输入模型和数据库实体:
1 | public class PersonInput |
再定义一个以 FromForm
形式接收参数的 Action:
1 | [HttpPatch] |
1 | curl --location --request PATCH 'http://localhost:5094/test/patch' \ |
如果客户端只提供了 Name
而没有其他参数,从 HttpContext.Request.Form.Keys
可以得知这一点。如果不使用 AutoMapper,那么就需要使用丑陋的判断:
1 | [HttpPatch] |
本文提供一种方式来简化这个步骤。
在有 CPU
和 GPU
参与的一种运算中,比如深度学习推理,CPU 需要预处理数据,然后交给 GPU 处理,最后 CPU 对 GPU 的运算结果进行后处理。
在整个过程中都是 FIFO
,即数据 ABC 按顺序输入,也需要按 A’B’C’ 顺序输出。
如果采用同步阻塞的方式,在 CPU 预处理时 GPU 处于空闲状态,GPU 运算时 CPU 后处理处于空闲状态并且也不能进行后续数据的预处理。这样影响整体的吞吐。
期望是 GPU 运算时,CPU 可以同时进行数据预处理和后处理。这是典型的单生产者单消费者模式。
在两个线程之间传递数据时,为确保线程安全,可以在一个线程每次 malloc
或 new
申请内存,在另一个线程 free
或 delete
。为了避免频繁的内存分配和释放,需要使用到内存池。
本文描述采用有界队列实现内存池,适用场景和限制: