半年，100%，建议在 20%～ 80%间使用电池，不要一边游戏一边充电，发热很伤电池

硬件中断，红黑树

内核 api 有不同 license，只要没调用 gpl 接口就可以不开源

可以 modinfo 看一下这个驱动设置的 license，如果不是 GPL，那是不能调用 GPL 接口的

ptrace 厉害了，思路清奇，顶一个

@hnes 你总结的没错，ucontext 上下文切换是相对比较耗时的。
posix 移除此接口原因是 makecontext 函数与 ISO C 不兼容，这个两个有差别吗？

c 的协程对编程的要求比较高，如果切换不合理，一不小心性能反而会下降，并且协程如果调用系统调用阻塞了，那整个任务也就挂住了。并且现在多核的情况下，协程并不能有效利用 CPU。

协程的本意是用户态调度，目的是让写代码的人，感知不到切换，也就是一个上下文做一件事情，没有状态，这是对比异步 IO+多路复用来说的。
但我觉得对于高并发程序，还是应该使用异步 IO+多路复用的模式来写，因为底层 API 对异步 IO 已经支持很好了。支持几十万，上百万处理不是问题。

go routine 在这方面其实优化的很好，不仅保证了写代码的便捷，同时保证了性能。

如果这个库能让 C 有类似的能力的话，就很好了。否则也只是特定的业务使用，并且还要小心使用。

这个轮子对比 libc 的 ucontext 协程有什么优势？

@zhiqiang
1. 动态库的话，直接调用日志接口，由主进程初始化日志模块。应该就没有问题了
2.目前采用的是环形队列，加锁是因为 vsnprintf 在写的时候，在调用 vsnprintf 的时候，实际上是加锁的，因为不知道结束的位置，如果要降低影响，可以搞一个日志队列，比如每个条日志固定最大 1K，缓冲几千条日志记录，应该就可以搞定，缺点就是浪费点内存，锁的话，就只锁队列添加、删除的时候了，这样就能满足业务要求了。
3.可以用宏封装，如下。
#define log_info(format, ...) tlog_ext(TLOG_INFO, BASE_FILE_NAME, __LINE__, __func__, 0, format, ##__VA_ARGS__)

@fakevam
pthread_at_fork 这个只能进程本身去处理。组件的话，没法处理。多线程的进程，用 fork 后还调用原进程接口。这个本身就是危险的。对应的 malloc，也有问题，对吗。

spinlock 那个，这个组件里面，没有用汇编，用汇编的话，就依赖硬件了。用的只是 gcc 的原子变量接口。先比 linux 内核，确实少了 nop 指令。之前用 gcc 接口的时候，也考虑过，所以代码里面时调用了 sched_yied()接口的。当然，这种改法确实没有大规模验证过

调用 localtime_r 这个修改是因为性能问题，这里现在实际上是没有问题的，因为这个函数外面是有一把 mutex 锁的。
性能是有一些影响，但考虑实际日志 20 万条，足够了，当前也就没有深入优化。

后面会继续优化。

TLS 也是解决办法，但 TLS 方案不一定比这个方案好。
因为，TLS 每个线程都要有缓冲区，日志线程写日志时，要遍历所有线程的 TLS 缓冲区。实现不会比这个高效。

总之，你提的意见都比较好，应该是高手了。你的建议我会考虑如何优化的。

@fakevam

@hilow
你说的这个 4K 是 libc 的机制，也就是依赖这个 4K 的话，只要单次写入大于 4K，日志就会拆分。这样是会混乱的。
并且多个文件并发写同一个文件是有会打印混乱的。

看了下 Linux 内核代码，sys_write 的调用，写时，对 inode 是加了锁的(调用__generic_file_aio_write 的时候)。所以用 append 模式写文件，能保证原子，tlog 日志模块每次写都是保证日志完整的。
在加上内核的这个锁，所以，tlog 日志并发写是没有问题的。你用 printf 写的话，是会有日志混乱的情况的。

ssize_t generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
unsigned long nr_segs, loff_t pos)
{
struct file *file = iocb->ki_filp;
struct inode *inode = file->f_mapping->host;
ssize_t ret;

BUG_ON(iocb->ki_pos != pos);

mutex_lock(&inode->i_mutex); 《==此处对 inode 加锁。
ret = __generic_file_aio_write(iocb, iov, nr_segs, &iocb->ki_pos);
mutex_unlock(&inode->i_mutex);

if (ret > 0 || ret == -EIOCBQUEUED) {
ssize_t err;

err = generic_write_sync(file, pos, ret);
if (err < 0 && ret > 0)
ret = err;
}
return ret;
}
EXPORT_SYMBOL(generic_file_aio_write);

@hilow
fprintf 直接写文件的话，遇到\n,或满 4k 的话，都会写盘的，并且硬盘繁忙的话，就会阻塞了，另外还有日志归档能力，自己写日志组件也不是没有意义的

@hilow
syslog 是个很好的日志组件,个人感觉适合记录量不大的日志，没见过大型后台服务直接写 syslog 的，或者有使用经验的话，也可以分享
appen 原子性,我在看看内核代码

@fakevam
厉害，提到的问题都很好。
1. 对于 fork 场景，只要多线程的进程，fork 一般都有问题，因为 fork 的是当前线程，内存又一样，fork 后如果调用原带锁的接口，极大概率死锁，大部分函数，包括 malloc，都是 fork-unsafe 的。所以目前，日志模块也并不支持 fork 出两个一模一样的带日志功能的进程。后面看看有什么好的办法，或者有什么好的建议。
2.这里多进程指的是通过 execve 启动的进程，进程间用文件锁互斥归档，open 的时候带 O_APPEND 并行写入。
3.spinlock 是比较简单，实现不公平，可能会饿死某些线程。单其实，tlog 格式化函数是有 mutex 锁的，这个 spinlock 其实没有意义。只是从接口完整性来讲，用 spinlock 保护了一下。另外，macOS 没有 pthread_spin_lock 锁，要不然就直接用了，不会自己写。后面优化。
4.自己没看到问题，spinlock 锁的时候，只有赋值的时候，其他调用 API 时是解锁的，还请指点一下。

@pkookp8
@neighbads
理论上，是存在日志互相串的。在 Linux 系统，fprintf 类是由缓冲的，一般这类函数在遇到\n 才刷盘的。
如果一次 fprintf 分了两次调用 write 写磁盘，那日志就会被拆分了。

可以加大日志量，就会高概率出现了。

另外，open 的时候，带 O_APPEND 标志，Linux 内核在 write 文件时，会保证原子性。
也是基于这个原理。我写的日志模块，可以支持多进程并发写同一个文件，并保证日志不会中间截断。

@changnet
主线程处理业务就好，日志的管理由日志线程处理，日志毕竟优先级比较低，不能影响业务。
日志一般要写磁盘的，并且还要压缩归档，如果磁盘繁忙，主线程不能因为磁盘忙阻塞的。所以需要异步日志。
当异步模式日志缓冲区满时，就丢弃日志，保证业务。（当然是可以配置的，可以选择阻塞，不丢日志）

正式上述原因，自己写了异步日志，上述代码已经在生产环境使用了，可以放心复用。

我看成每秒 60 万了，每天 60 万，也太少了。

卡=> very well  （笑）

who are we

hashmap?