PHPor 的Blog

流式解析http build query 字符串

脚本：

#!/bin/env php
<?php
$filter = isset($argv[1])?$argv[1]:"";
$arr = explode(".", $filter);
while(!feof(STDIN)) {
	$line = trim(fgets(STDIN));
	if (!$line) continue;
	$result = array();
	parse_str($line, $result);
	$notFound = false;
	foreach($arr as $key) {
		if ($key == "") continue;
		if (!isset($result[$key])) {
			$notFound = true;
			break;
		}
		$result = $result[$key];
	}
	if ($notFound) continue;
	if (is_array($result)) {
		print_r($result);
		echo "\n";
		continue;
	}
	if (is_string($result)) {
		echo "$result\n";
	}
}

#!/bin/env php

<?php

$filter = isset($argv[1])?$argv[1]:"";

$arr = explode(".", $filter);

while(!feof(STDIN)) {

$line = trim(fgets(STDIN));

if (!$line) continue;

$result = array();

parse_str($line, $result);

$notFound = false;

foreach($arr as $key) {

if ($key == "") continue;

if (!isset($result[$key])) {

$notFound = true;

break;

}

$result = $result[$key];

}

if ($notFound) continue;

if (is_array($result)) {

print_r($result);

echo "\n";

continue;

}

if (is_string($result)) {

echo "$result\n";

}

受jq的启发

这个parser很奇怪，处理的是 value 嵌套value的情况，生产上有这种情况，但是很少见。

tcp 的滑动窗口

tcp的滑动窗口是用来流控的，但是，如果一方不遵守，会怎样呢？如下：

我们发现，虽然8085一直提示说win只有430，但是59822却完全无视，直接发送1448大小的数据； 8085也没有生气，也没有不ack，是不是很好玩。

好景不长，59822 觉得不好意思了，改发500大小的数据包了：

对于甲方来说，发送了一个小的win ，乙方未必按照小的win发送数据，只要甲方总能ack乙方发送的所有数据，乙方就可以总是发送一个很大的数据包；对于甲方来讲，其实可以通过不ack乙方，或者ack部分数据来制服乙方的。

Windows目录无法删除的问题

如果在wsl中打开了某个目录，则在Windows上执行删除操作，虽然执行了删除操作，但是还是能看见，只是不能访问，直到wsl中退出该目录，该目录就会自动删除掉了

如何知道进程运行在哪个核上

下图是htop能直观看到的数据：

第一个CPU很忙，太多的时间花费在了内核，为什么内核那么消耗CPU：

该CPU主要干了三件事：

硬终端（估计这个是导致kacpid非常忙的根源）
软终端（主要是网卡中断）
内核进程kacpid

连续执行如下命令会发现acpi中断非常多，而且确实都是发生在CPU0上的，自然处理该中断的也就是CPU0了；如果说要把网卡软中断和acpi中断分开，那么就是，要么把acpi从CPU0挪走，要么把网卡软中断从CPU0挪走

cat /proc/interrupts |grep acpi

1	cat /proc/interrupts \|grep acpi

lua tcp udp

https://github.com/openresty/lua-nginx-module#ngxsocketudp

udp 支持unix dgram ，不需要连接池，可以把connect的结果保存到全局变量，但是，每次用完就close也开销不大

tcp 支持unix stream，通过set_keepalive 支持连接池

nginx多进程间的负载均衡

nginx是如何把任务分配到每个worker的呢？这种分配平均吗？合理吗？

通过strace 一个worker进程，部分逻辑如下：

我们发现，accept4是放在epoll_wait后面的，不难推测：

nginx的epoll_wait 是在看那个文件描述符有事件发生了（就是需要处理了），当然，这里不包含listen的那个文件描述符（不是不能，是不应该）；如果有事件发生，则处理，这些都是已经接收了的连接，有可能是（已建立的连接上的）新的请求。如果没有事件发生，则调用accept4看看有没有新的连接进来。这个逻辑就保证了，如果我比较闲，那么我就接活儿，如果我没闲着，我就不接活儿了

golang的chan阻塞与deadlock

示例：

func main() {
	c := make(chan int , 1)
        go func() { // 消费者
           <-c
        }()
	go func() {  // 如果没有这个协程，就得报deadlock而终止程序
		i := 0
		for {
			i++
		}
	}()
	c <- 1
	c <- 1
        c <- 1
}

func main() {

c := make(chan int , 1)

go func() { // 消费者

<-c

}()

go func() { // 如果没有这个协程，就得报deadlock而终止程序

i := 0

for {

i++

}

}()

c <- 1

}

如上程序：

如果没有第二个go协程，那么第一个协程是消费者，main协程是生产者，消费者死去后，就会出现deadlock错误；原以为是runtime检测到我们在写一个没人消费的chan感到奇怪而报错，实际上不是的，甚至也不是写不进去而报错，而是，没有一个协程是能被执行的了（就好比陈佩斯的小偷中说的那样，这大半夜的也每个车让我指挥指挥），所以，runtime才感觉很迷茫，就报了个deadlock；如果有第二个协程在的话，runtime会很高兴地去执行第二个协程的，真的不在意那个chan是否有人消费的。