Laputa

Seastar: sharded service(2)

Thu, 15 Dec 2022 00:00:00 +0000

Preface

第一篇里面介绍了一下 seastar::sharded 的基本概念和用法, 一般情况下我们用这些就足够了, 但是 Seastar 还为其他一些特殊的使用场景提供了支持, 当程序功能越来越复杂, 碰到这些场景的概率肯定会更大, 所以从完备的层面考虑, 还是得介绍一些他们; 其实也并不困难, Seastar 是秉持实用主义的, 也就是说在里面的组件一定是有现实中的使用场景的, 用到他们只是时间的问题(了解了这些组件之后可以在 redpanda 和 scylladb 的 codebase 里搜索一下具体的使用场景)

sharded parameter

前面并没有特别说明 seastar::sharded 的 start() 以及 invoke_on_* 系列函数允许传递哪些参数, 笼统地说只要是支持拷贝构造的类型(包括内置数据类型)都支持, 但是可以更具体地分为三类:

arbitrary constant values - these are copied to all instances
other sharded<> values - these are transformed before passing to the functor; the local instance is extracted and passed
shard-dependent parameter

第一类是最简单也是也是最常用的, 所有除了第二类和第三类说明的类型(sharded 和 sharded_parameter)外的其他类型都属于第一类, 比如 int、std::string 以及自定义类型 class Widget 等, 他们会被拷贝到各个 shard

Seastar: sharded service(1)

Thu, 01 Dec 2022 00:00:00 +0000

Preface

Seastar 是一个多线程异步库, 基于它的 App 通常都有在多个 shard(也称 logic core) 上对称部署服务的诉求; 为此我们需要在多个 shard 上创建服务的实例, 并且让这些实例执行某些操作; 这些涉及到 shard 之间的通信, Seastar 提倡使用显式的消息传递(message passing)而不是传统多线程编程常用的共享内存&加锁的方式进行通信, 为此提供了 smp 工具; 所以我们其实可以这样写:

c++

std::vector<Service> instances; 
instances.resive(smp::count);

smp::invoke_on_all([&instances]() {
 instance[this_shard_id()] = new Service();
});

使用 smp 中的工具, 我们可以实现这些操作, 但是如果有很多这样的服务, 那么就需要重复大量类似的代码(以上代码只是该场景下很小的一部分), 所以我们应该将其沉淀为一个通用的组件, 而 Seastar 也是这样做的, 这就是 seastar::sharded.

一开始它并不叫这个名字, 而是 seastar::distributed, 即分布式服务, 后面考虑到 distributed 经常用于跨机器的场景, 而这里实际上是同机器跨核, 所以改名为 seastar::sharded, 不过考虑到向前兼容还是把 seastar::distributed 作为 seastar::sharded 的一个别名保留, 只是不再推荐使用

一个 🌰

在了解它的实现之前, 先看看它的一些用法, Seastar 提供了一个简易的 HTTP server, 以此为例, 看看如何使用 sharded 在多个 core 上部署它; 为了简化逻辑, 使用 seastar::async 以串行的方式写:

Seastar: network stack

Sun, 13 Nov 2022 00:00:00 +0000

Seastar: network stack

Preface

Seastar 中提供了两种协议栈:

native stack
posix stack

其中 native stack 是 seastar 自己实现的一套协议栈, 一般是和 DPDK 配合使用; 而 posix stack 则是传统的内核协议栈; 由于我并不了解 DPDK, 暂时也没有学习/使用的需要, 所以目前还是先关注 posix stack 的实现(只关注 TCP, unix socket/UDP/SCTP 暂时不管), 以及 seastar 是如何抽象 network stack 这个概念从而统一 native stack 和 posix stack 二者的.

network stack API

为了统一 native stack 与 posix stack, seastar net 模块中抽象除了如下实体：

socket: 可以视作调用了 socket(2) 但是还没有 connect(2) 的 fd, 通过它我们可以发起网络连接得到 connected_socket
connected_socket: 一个处于连接状态的 TCP/SCTP 全双工流
server_socket : TCP/SCTP 监听描述符, 等待 accept(2) 新的网络连接
udp_channel: udp 管道, 用于读写数据
udp_datagram: udp 数据报
network_stack:

socket

This class is responsible for establishing a connection between two endpoints. It allows for the connection attempt to be canceled.

一个符号导致的问题

Sun, 07 Aug 2022 00:00:00 +0000

Preface

最近在优化 Seastar 中 httpd 的一些逻辑，完事之后跑一跑单测想确认下对现有逻辑的确无影响，但是一跑发现有一个 chunk 相关的测试挂了——但是我明明还没有改动到这块，只是改了一下 keepalive 的判定逻辑。

细究之后发现还是挺有意思的，所以打算把它记录下来；当然也不仅仅只是记录这个问题，查这个问题的时候也顺便学习了一下 Seastar 的单测该怎么写怎么执行、httpd 中 HTTP 协议解析流程，HTTP 中的 trailer 概念，以及 ragel 这个新工具的使用，所以也一并记录下来(同时也说明文章很有可能会抓不住重点 :))

问题

单测是这样：

c++

SEASTAR_TEST_CASE(test_full_chunk_format) {
 return check_http_reply(
 {
 "GET /test HTTP/1.1\r\n"
 "Host: test\r\n"
 "Transfer-Encoding: chunked\r\n\r\n",

 "a;abc-def;hello=world;aaaa\r\n"
 "1234567890\r\n",

 "a;a0-!#$%&'*+.^_`|~=\"quoted string obstext\x80\x81\xff quoted_pair: \\a\"\r\n"
 "1234521345\r\n",

 "0\r\n"
 "a:b\r\n"
 "~|`_^.+*'&%$#!-0a: ~!@#$%^&*()_+\x80\x81\xff\r\n obs fold \r\n"
 "\r\n"
 },
 {
 "12345678901234521345",
 "abc-def",
 "hello=world",
 "aaaa",
 "a0-!#$%&'*+.^_`|~=quoted string obstext\x80\x81\xff quoted_pair: a",
 "a: b",
 "~|`_^.+*'&%$#!-0a: ~!@#$%^&*()_+\x80\x81\xff obs fold"
 },
 false,
 new echo_string_handler()
 );
}

这个单测主要是为了测试 httpd 是否能正确解析 chunked 数据——通过 chunked_source_impl；

Seastar: temporary buffer

Sat, 16 Jul 2022 00:00:00 +0000

Preface

temporary_buffer 是 Seastar 提供的一种自我管理(self-managed)字节缓冲区，它类似于 std::string 或者 std::unique_ptr<char[]>，但是提供了一些更加灵活的内存管理机制，比如它可以独占底层的缓冲区，也可以和其他 temporary_buffer 共享底层缓冲区、甚至只共享其他 temporay_buffer 底层缓冲区的一部分…，因为这些功能，这个数据结构在 Seastar 以及 Scylla/RedPanda 等基于 Seastar 的项目中使用得非常广泛

temporary buffer

首先来看看其结构定义：

c++

template<typename CharType>
temporary_buffer {
 CharType *_buffer;
 size_t _size;
 deleter _deleter;
};

非常简单的一个结构，其中 _buffer 就是其底层缓冲区，_size 就是该缓冲区的大小；但是需要注意的是，由于 temporay_buffer 是可以从其他 temporary_buffer 共享的(甚至只共享一部分)，所以 _buffer 可能并是最初分配的内存的起始地址，因此 _size 也可能并不是最初分配内存的大小

二者的关系可能是这样：

而 deleter 自然就是用来释放该内存的工具了，相关逻辑暂且按下不表，后面会用另外一个 section 来解读，还是很有趣的

构造 & 析构

首先来看看它的构造和析构函数：

c++

explicit temporary_buffer(size_t size)
 : _buffer(static_cast<CharType*>(malloc(size * sizeof(CharType)))), _size(size)
 , _deleter(make_free_deleter(_buffer)) {
 if (size && !_buffer) {
 throw std::bad_alloc();
 }
 }

temporary_buffer(CharType* buf, size_t size, deleter d) noexcept
 : _buffer(buf), _size(size), _deleter(std::move(d)) {}

temporary_buffer() noexcept
 : _buffer(nullptr)
 , _size(0) {}

一个是默认构造函数，另一个则是指定缓冲区的大小，然后用 malloc 分配指定大小的缓冲区，此时 deleter 通过 make_free_deleter 构造出来，它的功能和它的名字一样：通过 std::free 释放 _buffer；还有一个则是直接传入 raw buffer 和 size，以及自定义deleter

Seastar: 用户线程

Sun, 22 May 2022 00:00:00 +0000

Preface

通常我们在 seastar 中写代码是不能阻塞的，如果我们希望在一段异步代码之后执行完毕之后开始执行另外一个逻辑，那么我们就需要通过 continuation 的方式将其串联起来，比如：

c++

seastar::sleep(2s).then([]() {
 /* another code piece */
})

而不能直接调用 future::get() 或者 future::wait()：

c++

seastar::sleep(2s).wait();

/* another code piece */

以上代码在 wait() 的过程中就会 core dump。

但是 seastar 提供了 seastar::thread 这个工具，通过它，我们可以正常执行可能导致阻塞(即 future::wait())的代码：

c++

ss::thread th([]() {
 using namespace std::chrono_literals;
 ss::sleep(2s).wait();
 std::cout << "Hello, seastar thread!" << std::endl;
});
return ss::do_with(std::move(th), [](seastar::thread &th) {
 return th.join();
});

实际上其内部并没有阻塞，但是却产生了以同步方式写异步代码的效果(通过 ucontext)，有点 async/await 的感觉；这个工具在单测中用的非常普遍，而且像 scylla 和 redpanda 的 main 函数都是通过它启动的。

`seastar::async`

虽然我们可以像上面一样直接使用 seastar::thread，但是却要处理等待 thread 结束(join())、生命周期管理等问题，所以 seastar 更推荐我们使用 seastar::async 这个函数，比如之前的代码通过该函数可以改写成这样：

ucontext and coroutine

Sun, 08 May 2022 00:00:00 +0000

Preface

最近在看 seastar::thread 的实现，暂且不说它的巧妙(实际上目前还没有完全看懂，但是 Seastar 出品，必属精品)，我首先注意到了 ucontext，这是 seastar::thread 中能够等待一个 unavailable future 的关键，之前没有接触过这套 API，网上搜索了一下相关资料才了解到它居然可以用来实现协程，顿时有了兴趣。

学习 OS 时我们就知道线程有几种实现方式：在内核态中实现、在用户态中实现以及混合实现；内核级线程我们已经在 pthread 中见识过了，用户态的线程，或者说协程，在不少语言中都有实现，比如 Lua 的 coroutine，Golang 的 goroutine。

对于 pthread 线程，操作系统会对它们进行调度，使用者需要做的更多是处理线程之间的通信与同步；而到了协程，则不是这样了，OS 压根不知道它们的存在，所以它们的调度也得由使用者来做，比如 Lua 的 coroutine——用户需要决定该执行哪一个协程以及何时切换到其他协程，Golang 的 goroutine(GMP 模型应该看做是混合实现)则更近一步——从语言层面就接管了协程的调度，大大减少了协程的使用负担，用户只需要专注于自己的业务逻辑——放心地 go ，Golang runtime 自会让 goroutine 之间高效地配合运行。

ucontext

ucontext 也可以用来实现协程，它整体来看还是类似于 Lua coroutine —— 需要用户去调度执行；我们知道，不论是 thread 还是 coroutine 调度/切换，都需要保存当时的执行上下文，以便后续可以回去继续执行；thread 的上下文由 OS 保存维护，对用户是透明的；而这里 coroutine 要用户来进行调度，所以其上下文对用户自然也是可见的——就是 ucontext，即 user thread context——用户级线程的执行环境，其中保存着 coroutine 执行所需要的栈、寄存器、信号等信息；通过它，我们可以很方便地在 uthread 之间进行切换

ucontext_t在 Linux 5.15 中其定义如下：

typedef struct ucontext_t
 {
 unsigned long int __ctx(uc_flags);
 struct ucontext_t *uc_link;
 stack_t uc_stack;
 mcontext_t uc_mcontext;
 sigset_t uc_sigmask;
 struct _libc_fpstate __fpregs_mem;
 __extension__ unsigned long long int __ssp[4];
 } ucontext_t;

typedef struct
 {
 void *ss_sp;
 int ss_flags;
 size_t ss_size;
 } stack_t;

其中以 uc 开头的几个字段是比较常用的：

Seastar: semaphore

Wed, 04 May 2022 00:00:00 +0000

Preface

最近在实现 fetch 接口时, 需要对单个 JS 脚本的单次执行过程中可以发起的 fetch 操作数进行限制(和 CloudFlare Workers 类似):

总量限制：超过了则后续的 fetch 操作都将直接失败
并发限制：超过了则后续的 fetch 请求将会被延迟(postpone)执行，直到有其他执行着的 fetch 请求结束

第一点很简单, 用一个计数器即可解决; 关键在于第二个, 要将超出了并发限制的 fetch 操作阻塞住, 直到有其他 fetch 操作结束(即返回的 promise 被 resolve)再唤醒它们执行.

这个需求听起来似乎很熟悉？可以换一种说法，将「同一个时刻可运行的 fetch 请求」视为一种资源，这个资源是可以重复利用的(这一点是并发限制和总量限制的主要区别)：发起一个 fetch 请求相当于拿走一份资源，结束一个 fetch 请求相当于归还一份资源；且这个资源并非无限，所以当资源被拿完之后再想拿就等着直到有人归还资源。

说到这里就很清晰了，这个问题就是信号量(semaphore)¹要解决的：

In computer science, a semaphore is a variable or abstract data type used to control access to a common resource by multiple threads and avoid critical section problems in a concurrent system such as a multitasking operating system.

Seastar: 系统调用线程

Mon, 18 Apr 2022 00:00:00 +0000

Preface

在 Seastar 中，文件相关的操作并不直接由 reactor 线程(工作线程)执行，而是被 offload 到一个专门的线程中去执行，为此 Seastar 在 reactor 中提供了诸多文件操作相关的方法；比如重命名一个文件就可以使用 rename_file 方法：

c++

static ss::future<> f() {
 return ss::engine()
 .rename_file("hello.txt", "world.txt")
 .then_wrapped([](ss::future<> &&fut) {
 if (fut.failed()) {
 fmt::print("rename file failed: {}", fut.get_exception());
 }
 return ss::make_ready_future<>();
 });
}

所有这些文件操作相关的函数都返回 future

源码剖析

每个 reactor 中都有一个类型为 thread_pool 的变量，但是我觉得有点名不副实，因为它并不是一个 pool，而只是一个单独的线程——仅仅用于执行文件相关的 syscall，所以叫 syscall thread 或许会更好一些；不过这些都是细枝末节，先看看 rename_file 的实现：

c++

future<>
reactor::rename_file(std::string_view old_pathname, std::string_view new_pathname) noexcept {
 // Allocating memory for a sstring can throw, hence the futurize_invoke
 return futurize_invoke([old_pathname, new_pathname] {
 return engine()._thread_pool->submit<syscall_result<int>>([old_pathname = sstring(old_pathname), new_pathname = sstring(new_pathname)] {
 return wrap_syscall<int>(::rename(old_pathname.c_str(), new_pathname.c_str()));
 }).then([old_pathname = sstring(old_pathname), new_pathname = sstring(new_pathname)] (syscall_result<int> sr) {
 sr.throw_fs_exception_if_error("rename failed", old_pathname, new_pathname);
 return make_ready_future<>();
 });
 });
}

逻辑非常简单，就是往 syscall thread 中提交一个任务，该任务也不过是简单地调用了一下 rename¹ 这个系统调用；如果该调用出错，则抛出异常——当然被 futurize_invoke 捕获并转换为一个 exceptional future 返回给调用方。

Seastar：核间通信

Sat, 02 Apr 2022 00:00:00 +0000

Preface

虽然 Seastar 号称 share-nothing¹，但是现代服务器开发中仍免不了需要核间通信；Seastar 为此在 smp 类中提供了 submit_to 方法用于向其他线程的 reactor 提交任务并执行：

c++

static futurize_t<std::invoke_result_t<Func>>
submit_to(unsigned t, Func&& func) noexcept;

比如下面的代码：

c++

ss::future<> f() {
 std::cout << "run on shard-" << ss::this_shard_id() << std::endl;
 return ss::smp::submit_to(1, []() {
 std::cout << "run on shard-" << ss::this_shard_id() << std::endl;
 });
}

首先在当前 shard 打印其 id，然后往 id 为 1 的 shard 提交一个异步任务，该异步任务也只是简单地打印出所在 shard 的 id

使用 app_template 执行该函数得到结果：

shell

% sudo ./my_app -c 2
run on shard-0
run on shard-1

的确第二句 std::cout 是在 shard-1 上执行的；这里需要注意由于使用了两个 shard，所以至少需要使用两个核(-c 2)。

源码剖析

这里涉及到两个核之间的通信，所以有必要先规定几个叫法：

local core/local shard/local reactor：指发起通信的一方
remote core/remote shard/remote reactor：指接收方

前面提到的 submit_to 函数实际上是以默认的 smp_submit_to_options 参数调用的下面这个函数：

Seastar: loop utility

Sat, 26 Mar 2022 00:00:00 +0000

Preface

循环是绝大多数编程语言中必不可少的控制结构，比如 C++ 对数组中的元素求和：

c++

int sum(const std::vector<int> &ints) {
 int res = 0;
 for (size_t i = 0; i < ints.size(); i++) {
 res += ints[i];
 }
 return res;
}

然而在 Seastar 中，写循环却不是一件容易的事情——当然不是上面这种不涉及到任何的异步操作的循环，而是指循环重复执行一个异步操作。比如我们想实现这样一个 search 函数：它依次从 Google、Bing 和 Baidu 搜索，有一个成功则将其内容输出至标准输出并停止搜索；或许我们可以马上写出下面这样一段代码：

c++

extern ss::future<std::string> fetch(const std::string &domain,
 const std::string &object);

void search(const std::string &object) {
 static std::vector<std::string> domains = {
 "www.google.com",
 "www.bing.com",
 "www.baidu.com",
 };
 for (size_t i = 0; i < domains.size(); i++) {
 auto fut = fetch(domains[i]);
 if (!fut.is_failed()) {
 std::cout << fut.get0() << std::endl;
 return;
 }
 }
}

然而 fetch 函数是一个异步操作，也就是说，这个函数不会阻塞，而是立即返回；而它返回的 future 很大程度上不是 ready 的，所以我们无法判断其状态，除非我们等待，然而这就失去了异步的意义(而且 Seastar 不允许我们在非 seastar::thread 环境中等待一个 future)。

再退一步，就算我们不考虑「有一个成功则返回」这个逻辑，而只是「依次向 Google、Bing 和 Baidu 发起请求」，我们也做不到：

c++

for (size_t i = 0; i < domains.size(); i++) {
 (void) fetch(domains[i]).then_wrapped([](ss::future<std::string> &&fut) {
 if (fut.failed()) {
 std::cout << "fetch FAILED: " << fut.get_exception() << std::endl;
 } else {
 std::cout << "fetch SUCCEEDED: " << fut.get0() << std::endl;
 }
 });
}

还是之前的原因，fetch 是一个异步操作不会阻塞而是直接返回，所以这里无法保证「在前一个操作完成之后再进行下一个」这个逻辑。

Seastar: FPC(2)

Wed, 09 Mar 2022 00:00:00 +0000

Preface

这里不打算完整地解释 Seastar 中 future&promise 的实现，里面旁枝末节实在太多，比如：

API 的兼容性处理
针对不同平台的优化
针对 Debug 编译的特殊处理
各种 Modern C++ 特性的使用
针对 GCC/Clang 做的各种编译优化
…

所以还是希望抓住其中的一些重难点以及做的一些优化进行分析。

这个系列的第一篇文章¹中已经 future&promise 的大致实现流程进行了解释，Seastar 整体思想与之类似，但是还是有一些不同²：

Seastar 作为一个网络框架，绝大多数时候面对的是重 I/O 的任务，所以它并不使用扩展性并不强的多线程模型，而是采用事件驱动的方式异步执行用户代码
因为 future&promise 都在同一个线程中操作，所以也不需要加锁，所以忘记前面的 std::mutex 和 std::condition_variable 吧
为了极致的性能，Seastar 中的 future&promise 并不需要动态分配内存，所以也忘记前面的 std::shared_ptr<SharedState> 吧

类层次结构

首先看看 FPC 的类结构，这里直接放出其 UML 图：

非常复杂的层次结构，关于图片有几点注意：

对于模板类，在 UML 图矩形的右上角标注了其模板类型参数
uninitialized_wrapper_base 有两种偏特化实现，但是这里只标注了其一
存在 public 和 private 继承，但是在 UML 图中没有表示出来

从之前的 SharedState 我们可以总结出，future 和 proimise 的共享状态需要包含 future 的状态，异常值、数据；在 Seastar 中这一角色由 future_state 承担：其中数据从 uninitialize_wrapper 中继承，状态、异常值则从 future_state_base 中继承。

Seastar: FPC(1)

Sun, 06 Mar 2022 00:00:00 +0000

Preface

主要讲的是 future&promise 一些基本概念以及设计原理，但是因为 Seastar 中的实现¹非常复杂(毕竟是工业级产品，且经过了 LLVM 大牛的大量优化，多了许多与核心实现其实并没有关系的逻辑)，所以我并不打算直接硬上(其实之前尝试过好几次，但是看完了之后还是迷迷糊糊一知半解，所以打算换一种方法)，而是打算借助 CppCon 2015 上的一个 presentation² 来介绍它的基本原理和简易实现；BTW，这个 presentation 的确讲的非常好，力荐！

Future and Promise

标题中的 FPC 指的是 Future、Promise 和 Continuation 这三个概念，这是并发编程中非常常见的一种编程模型；首先不管 Continuation 是什么，先了解 Future 和 Promise；Wikipedia 是这样解释³的：

In computer science, future, promise, delay, and deferred refer to constructs used for synchronizing program execution in some concurrent programming languages. They describe an object that acts as a proxy for a result that is initially unknown, usually because the computation of its value is not yet complete.

Boost: 侵入式容器

Sat, 05 Mar 2022 00:00:00 +0000

Preface

最近在为 Lua/JS 子请求实现 HTTP 连接池，池子的大小是固定的，但是创建的连接数是由跑在我们 web server 之上的用户代码(Lua/JS)决定的，所以在空间不够时必然需要淘汰旧的连接。很容易想到 LRU 淘汰算法，通常我们使用哈希表+双向链表实现¹：哈希表用于存储数据，并且支持 $\mathcal{O}(1)$ 查找；而双向链表用于维护元素的访问时序，并且可以$\mathcal{O}(1)$ 删除。

侵入式容器

现在我已经有了哈希表，只是缺一个双向链表记录元素的访问时序。很容易想到 STL 中的 std::list，这是最常见的选择，但最终我没有用它，而是选择了 boost::intrusive::list。

std::list(以及标准库中的其他容器)是非侵入式的，而 boost::intrusive::list 则是一种侵入式容器。所谓侵入式和非侵入式，其实指的是容器是否入侵了对容器所容纳的元素类型。

对于 std::list，其节点和原始对象的关系如下：

txt

|--------------|
| next |
| prev |
| |--------| |
| | OBJECT | |
| |--------| |
|--------------|

可以看到，链表节点其实是对原始对象的一层包裹，并加上了前后指针；每次插入一个对象分配节点时时，都需要将原始对象拷贝进去。

如果原始对象很大，或者它不支持拷贝，那么怎么办呢？此时可以考虑让链表存储对象的指针(比如 std::list<T*>)，但是这仍免不了额外的内存分配以及数据拷贝(此时有一个指针的拷贝，以及三个指针大小的内存分配，使用智能指针的话则更多，并且还会影响引用计数)。

而对于 boost::intrusive::list，其节点和原始对象的关系如下：

txt

|--------------|
| OBJECT |
|--------------|

对象即节点，节点即对象；也就是说侵入式容器直接将对象本身作为链表节点，所以并不会产生额外的内存分配以及数据拷贝；而链表之所以是链表，是因为元素存在着指向其他元素的链接，所以直接使用原始对象作为链表节点的话，就需要对象中本身就包含指向其他元素的指针，这是使用侵入式容器的前提(precondition)，所以对象在设计的时候就需要将其考虑进去，所以说它是侵入式的。

倘若元素只存储在一个容器中，那么二者的效率并没有区别：都需要为对象和前后指针分配内存，无非是原始对象由容器还是对象本身来分配的问题，而且 std::list 会替用户管理对象的生命周期，使用起来还会更加方便。但是在 LRU 的情况下，对象需要出现在两个容器中，这个时候侵入式容器的价值就体现出来了。

做一下总结²：

非侵入式链表(如 std::list)：由链表来管理对象的生命周期，且不需要用户维护前后指针，但是缺点在于它需要进行额外的内存分配以及数据拷贝。
侵入式链表(如boost::intrusive::list)：需要用户自己在对象中加上前后指针，对象的生命周期由用户自己管理，但是不需要额外的内存分配以及数据拷贝。

侵入式容器在平常的业务开发中使用的比较少，但是在许多框架中则使用得非常广泛，比如 Linux 内核中的 struct list_head，Nginx 中的 ngx_queue_t 和 ngx_rbtree_t…

V8: 模板(1)

Thu, 17 Feb 2022 00:00:00 +0000

Preface

当我们在 web server 中做 v8 扩展开发时，我们在做些什么？

可以和 OpenResty 中的 Lua 类比，其中很大一部分工作是将 web server 的原生(native)能力暴露在 JS 中供用户使用。在 Lua 中写 C/C++ API 我们只需要遵守它所要求的函数签名以及参数传递机制写函数并将其注入全局环境就足够了，比如：

c++

static int ngx_readfile(lua_State *L) {
 int nargs = lua_gettop(L);
 if (nargs != 1) {
 return luaL_error("expecting one argument but seen %d", nargs);
 }

 ngx_str_t data;

 /* ... open file and read its content to text ... */

 lua_pushlstring((const char *)data.data, data.len);
 return 1;
}

lua_pushcfunction(L, ngx_readfile);
lua_setglobal(L, "readfile");

这样我们就可以在 Lua 中使用 readfile() 直接执行 ngx_readfile 函数；事实上，Lua 标准库中所有的 API 也是这样暴露出去的。

V8 中的做法也大同小异，只是通过模板做了封装；这里所说的模板并不是 C++ 中的 Template，而是 V8 中的概念，但既然二者都是一个名字，那必然是有相似之处的；v8 embed doc 中对模板的解释是这样的：

Lua: read-only table

Sat, 29 Jan 2022 00:00:00 +0000

Preface

Lua 中的 API 都是以 Lua table 的方式存储并提供给用户使用，拿 OpenResty 中的 ngx.say API 为例：其中 ngx 是全局环境(也是一个 Lua table)中一个名为 ngx 的 key 对应的 value(一个 table)，而 say，则是 ngx 这个 table 中一个名为 say 的 key 对应的 value(一个 C function)；而 Lua 标准库也是如此。

在 OpenResty 的实现中，每个 Nginx worker 启动时会创建一个 Lua 虚拟机(即 lua_State)，在初始化该 vm 时，会将 OpenResty 提供的 API 注入 Lua 的全局环境，以及替换掉标准库的一些实现(比如 coroutine API)，具体逻辑在 ngx_http_lua_new_state() 以及 ngx_http_lua_init_globals() 这两个函数中；逻辑很简单，主要是一些 Lua table 相关的操作，就不贴代码了。而后每次请求到来时，OpenResty 都会在本进程的 Lua vm 之上创建一个 coroutine 用于服务该请求，而该 coroutine 会使用之前创建好了的全局环境(具体代码可见 ngx_http_lua_content_by_lua() 函数)；这样用户就可以在脚本中使用 OpenResty 提供的所有 API。

Lua: buffer system

Sun, 14 Nov 2021 00:00:00 +0000

Preface

最近在实现一套和 OpenResty 中的 ngx.re.* 类似的 API，其中 gsub/sub 这俩用到了 luaL_Buffer；在数据量比较小的情况下它工作的很好，可是一旦数据量上去了，程序就开始抛出异常，不过 OpenResty 却可以正常工作，着实困扰了我一阵；查阅资料发现网上说 luaL_Buffer 的确比较坑，怀疑是不是我用的方式不太对；最终通过看内部实现发现了问题所在，写这篇 blog 记录下

基本使用

可以简单将 luaL_Buffer 理解为一个 String Builder，即拼接字符串的工具，Lua 它的定义为：

A string buffer allows C code to build Lua strings piecemeal.

一般是这样使用的：

声明一个 luaL_Buffer 类型的变量 b
使用 luaL_Bufferinit(L, &b) 初始化它
通过 luaL_add*() 系列函数往该 buffer 中添加一部分字符串
通过调用 luaL_pushresult(&b) 结束字符串的构建，调用返回后会将最终得到的字符串放在栈顶

此外， manual 对 luaL_Buffer 还加了一个额外的描述：

During its normal operation, a string buffer uses a variable number of stack slots. So, while using a buffer, you cannot assume that you know where the top of the stack is. You can use the stack between successive calls to buffer operations as long as that use is balanced; that is, when you call a buffer operation, the stack is at the same level it was immediately after the previous buffer operation. (The only exception to this rule is luaL_addvalue After calling luaL_pushresult, the stack is back to its level when the buffer was initialized, plus the final string on its top.

程序员修炼之道: 务实的哲学

Sat, 19 Sep 2020 00:00:00 +0000

Preface

自接触编程以来，我看过的绝大部分书都是关于某项特定技术的，比如 C++ Primer、深入理解 Nginx 以及 OS、网络等计算机专业课相关的。诚然，这些都是必备的，但是正式工作后，越来越感觉如何成长是一个至关重要的议题，而正好《程序员修炼之道》第二版发布了，所以打算看看这本书，而实际上书的确很棒，仅第一章里面就有许多地方我深有同感，不过许多地方我想的并不全面，也缺乏归纳总结这些思想的能力；还是先摘抄一些我喜欢的段落。

P.S(1) 20 年并没有看完这本书，22 年重新看并打算看完它；在之前的博客中发现了这篇，想想还是把它贴出来吧，因为第二遍看这本书我还是非常喜欢
P.S(2) 务实(pragmatic)这个词我非常喜欢，它和靠谱(reliable)一起构成了我对他人的最高评价词，当然我也希望成为这样的人

一、前言

编程是一门技艺。简单地说，就是让计算机做你想让它做的事情（或者是你的用户想让它做的事情）。作为一名程序员，你既在倾听，又在献策；既是传译，又行独裁；你试图捕获难以捉摸的需求，并找到一种表达它们的方式，以便仅靠一台机器就可以从容应付。你试着把工作记录成文档，以便他人理解；你试着将工作工程化，这样别人就能在其上有所建树；更重要的是，你试图在项目时钟的滴答声中完成所有的这些工作。你每天都在创造小奇迹。

你不应该拘泥于任何特定的技术，而应该拥有足够广泛的背景和经验基础，以便在特定的情况下选择合适的解决方案。你的背景来自对计算机科学基本原理的理解，而你的经验来自广泛的实际项目。理论结合实践会让你变得强大。

调整方法去寻找适应当前的情况和环境。对所有影响项目因素的相对重要性做出判断，并通过经验找到合适的解决方案。随着工作的进展，你要不断地这样做。务实的程序员不仅把工作做完，并且做得很好。

二、务实的哲学

务实的程序员的特质是什么？是他们面临问题时，在解决方案中透出的态度，风格以及理念。他们总是越过问题的表面，试着将问题放在更宽泛的上下文中综合考虑，从大局着想。毕竟，若不去了解来龙去脉，结合实际从何谈起？又怎能做出明智的妥协和合理的决策？

当你意识到自己在说“我不知道”时，一定要接着说“——但是我会去搞清楚”。用这样的方式来表达你的不知道是非常好的，因为接着你就可以像一个专家一样承担起责任。

不要只是因为一些东西非常危急，就去造成附带损害。破窗一扇都嫌太多。

批判性地分析你读到和听到的东西，问几个值得思考的问题：

谁从中受益

有什么背景：每件事都发生在自己的背景之下，这也是为何“能解决所有问题”的方案通常是不存在的。

什么时候可以在哪里工作起来：不要停留在一阶思维下（接下来会发生什么），要进行二阶思考（当它结束后还会发生什么？）。

为什么这是个问题：是否存在一个基础模型以及这个基础模型是怎么工作的？

归档

Mon, 01 Jan 0001 00:00:00 +0000

搜索

Mon, 01 Jan 0001 00:00:00 +0000