Aria2 是一款轻量级的命令行下载工具，支持 HTTP/HTTPS、FTP、SFTP、BitTorrent 和 Metalink 等链接格式，提供 JSON-RPC 和 XML-RPC 管理接口，是一款优秀的 Linux 版迅雷替代品。

周末折腾了半天，终于将博客从 Pelican 转到了 Hexo，在此记录一下。

方案选择

首先说说方案选择，目前博客系统大致分为静态和动态两类，动态博客有 Wordpress、Ghost 等等，因为需要单独的主机和搭建环境，并且数据存在 DB 迁移起来比较费劲，所以放弃了这种方案；静态博客有 Pelican、Jekyll、Hexo 等等，后者很多优点，访问速度快，博客可直接用 Markdown 以文件的形式保存在 Github，借助 Github Pages 部署方便，不用自己搭建主机，总之个人觉得这些优点可以完爆动态博客。

笔者之前的博客是基于 Pelican 的，因为使用 Python 写的，而自己对 Python 有一种痴迷，因此之前选用了这种方案，但是慢慢发现缺点有很多。首先是渲染速度慢，当文章越来越多时，博客生成的时间就会让人难以忍受。另外 Pelican 的主题都不是很炫，找了半天都没有找到好看的主题，这也是促使我选用其他博客系统的一个原因。

其次了解了 Jekyll，它是用 Ruby 开发的，也是 Github 主推的博客系统，和 Github 无缝结合，可以直接在 Github 页面上配置、修改主题（教程在此），主题也很多，如果没有遇见 Hexo，也许我会选择 Jekyll。

Hexo 使用 Nodejs 开发，渲染速度相对于 Python 和 Ruby 来说很快，而且 CLI 设计也非常人性化，配置简单，支持的插件也有很多，使用 npm 来管理。也许正是由于开发语言的关系，Hexo 的主题质量都非常高，都非常好看，让人眼花缭乱（https://hexo.io/themes/index.html）。老实说我是被这款名叫 AlphaDust 的主题吸引了，非常有科技感，而且响应式在移动设备上也比较完美，无论是英文字体还是中文字体都支持很好，对作者的敬意油然而生。当然 NexT 也是一款非常优秀的主题，以后有机会可以尝试一下（^_^）。

原文地址：http://blog.codingnow.com/2008/06/gc.html

本质上来说，引用计数策略和垃圾收集策略都属于资源的自动化管理。所谓自动化管理，就是在逻辑层不知道资源在什么时候被释放掉，而依赖底层库来维持资源的生命期。

而手工管理，则是可以准确的知道资源的生命期，在准确的位置回收它。在 C++ 中，体现在析构函数中写明 delete 用到的资源，并由编译器自动生成的代码析构基类和成员变量。

所以，为 C++ 写一个垃圾收集器，并不和手工管理资源冲突。自动化管理几乎在所有有点规模的 C++ 工程中都在使用，只不过用的是引用计数的策略而非垃圾收集而已。也就是说，我们使用 C++ 或 C 长期以来就是结合了手工管理和自动管理在构建系统了。无论用引用计数，还是用垃圾收集，软件实现的细节上，该手工管理的地方我们依旧可以手工管理。

为什么要用资源生命期自动管理？

Makefile 简介

在软件开发中，make通常被视为一种软件构建工具。该工具主要经由读取一种名为“makefile”或“Makefile”的文件来实现软件的自动化建构。它会通过一种被称之为“target”概念来检查相关文件之间的依赖关系，这种依赖关系的检查系统非常简单，主要通过对比文件的修改时间来实现。在大多数情况下，我们主要用它来编译源代码，生成结果代码，然后把结果代码连接起来生成可执行文件或者库文件。

优点与缺点

与大多数古老的Unix工具一样，make也分别有着人数众多的拥护者和反对者。它在适应现代大型软件项目方面有着许许多多的问题。但是，依然有很多人坚定地认为（包括我）它能应付绝大多数常见的情况，而且使用非常的简单，功能强大，表达清楚。无论如何，make如今仍然被用来编译很多完整的操作系统，而且它的那些“更为现代”的替代品们在基本操作上与它没有太大差别。

当然，随着现代的集成开发环境（IDE）的诞生，特别是非Unix的平台上，很多程序员不再手动管理依靠关系检查，甚至不用去管哪些文件是这个项目的一部分，而是把这些任务交给了他们的开发环境去做。类似的，很多现代的编程语言有自己专属的、能高效配置依赖关系的方法（譬如Ant）。

主要版本

make程序经历过各方多次的改写与重写，各方都依据自己的需要做了一些特定的改良。目前市面上主要流行有以下几种版本：

• GNU make： GNU make对make的标准功能（通过clean-room工程）进行了重新改写，并加入作者自认为值得加入的新功能，常和GNU编译系统一起被使用，是大多数GNU Linux默认安装的工具。

• BSD make： 该版本是从Adam de Boor制作的版本上发展起来的。它在编译目标的时有并发计算的能力。主要应用于FreeBSD，NetBSD和OpenBSD这些系统。

• Microsoft nmake： 该版本主要用于微软的Windows系统中，需要注意的是，微软的nmake与Unix项目中的nmake是两种不同的东西，千万不要混淆。

从一个简单的例子开始

我们可以用K&R C中4.5那个例子来做个说明。在这个例子中，我们会看到一份主程序代码 main.c、三份函数代码 getop.c、stack.c、getch.c以及一个头文件 calc.h。通常情况下，我们需要这样编译它：

1

gcc -o calc main.c getch.c getop.c stack.c 

如果没有makefile，在开发+调试程序的过程中，我们就需要不断地重复输入上面这条编译命令，要不就是通过终端的历史功能不停地按上下键来寻找最近执行过的命令。这样做两个缺陷：

一旦终端历史记录被丢失，我们就不得不从头开始；

任何时候只要我们修改了其中一个文件，上述编译命令就会重新编译所有的文件，当文件足够多时这样的编译会非常耗时。

那么 Makefile 又能做什么呢？我们先来看一个最简单的 makefile 文件：

1
2

calc: main.c getch.c getop.c stack.c
    gcc -o calc main.c getch.c getop.c stack.c 

现在你看到的就是一个最基本的Makefile语句，它主要分成了三个部分，第一行冒号之前的 calc，我们称之为目标（target），被认为是这条语句所要处理的对象，具体到这里就是我们所要编译的这个程序 calc。冒号后面的部分（main.c getch.c getop.c stack.c），我们称之为依赖关系表，也就是编译calc所需要的文件，这些文件只要有一个发生了变化，就会触发该语句的第三部分，我们称其为命令部分，相信你也看得出这就是一条编译命令。现在我们只要将上面这两行语句写入一个名为Makefile或者makefile的文件，然后在终端中输入make命令，就会看到它按照我们的设定去编译程序了。

请注意，在第二行的“gcc”命令之前必须要有一个tab缩进。语法规定Makefile中的任何命令之前都必须要有一个tab缩进，否则make就会报错。

接下来，让我们来解决一下效率方面的问题，先初步修改一下上面的代码：

1
2
3
4
5
6

cc = gcc
prom = calc
source = main.c getch.c getop.c stack.c

$(prom): $(source)
    $(CC) -o $(prom) $(source)

如你所见，我们在上述代码中定义了三个常量 cc、prom 以及 source。它们分别告诉了make我们要使用的编译器、要编译的目标以及源文件。这样一来，今后我们要修改这三者中的任何一项，只需要修改常量的定义即可，而不用再去管后面的代码部分了。

请注意，很多教程将这里的 cc、prom 和 source 称之为变量，个人认为这是不妥当的，因为它们在整个文件的执行过程中并不是可更改的，作用也仅仅是字符串替换而已，非常类似于C语言中的宏定义。或者说，事实上它就是一个宏。

但我们现在依然还是没能解决当我们只修改一个文件时就要全部重新编译的问题。而且如果我们修改的是 calc.h 文件，make就无法察觉到变化了（所以有必要为头文件专门设置一个常量，并将其加入到依赖关系表中）。下面，我们来想一想如何解决这个问题。考虑到在标准的编译过程中，源文件往往是先被编译成目标文件，然后再由目标文件连接成可执行文件的。我们可以利用这一点来调整一下这些文件之间的依赖关系：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

cc = gcc
prom = calc
deps = calc.h
obj = main.o getch.o getop.o stack.o

$(prom): $(obj)
    $(CC) -o $(prom) $(obj)

main.o: main.c $(deps)
    $(CC) -c main.c

getch.o: getch.c $(deps)
    $(CC) -c getch.c

getop.o: getop.c $(deps)
    $(CC) -c getop.c

stack.o: stack.c $(deps)
    $(CC) -c stack.c      

这样一来，上面的问题显然是解决了，但同时我们又让代码变得非常啰嗦，啰嗦往往伴随着低效率，是不祥之兆。经过再度观察，我们发现所有.c都会被编译成相同名称的 .o 文件。我们可以根据该特点再对其做进一步的简化：

1
2
3
4
5
6
7
8
9
10

cc = gcc
prom = calc
deps = calc.h
obj = main.o getch.o getop.o stack.o

$(prom): $(obj)
    $(CC) -o $(prom) $(obj)

%.o: %.c $(deps)
    $(CC) -c $< -o $@

在这里，我们用到了几个特殊的宏。首先是 %.o:%.c，这是一个模式规则，表示所有的.o目标都依赖于与它同名的 .c 文件（当然还有deps中列出的头文件）。再来就是命令部分的 $< 和 $@，其中$<代表的是依赖关系表中的第一项（如果我们想引用的是整个关系表，那么就应该使用 $^），具体到我们这里就是%.c。而$@代表的是当前语句的目标，即 %.o。这样一来，make命令就会自动将所有的 .c 源文件编译成同名的 .o 文件。不用我们一项一项去指定了。整个代码自然简洁了许多。

到目前为止，我们已经有了一个不错的makefile，至少用来维护这个小型工程是没有什么问题了。当然，如果要进一步增加上面这个项目的可扩展性，我们就会需要用到一些Makefile中的伪目标和函数规则了。例如，如果我们想增加自动清理编译结果的功能就可以为其定义一个带伪目标的规则；

1
2
3
4
5
6
7
8
9
10
11
12
13

cc = gcc
prom = calc
deps = calc.h
obj = main.o getch.o getop.o stack.o

$(prom): $(obj)
    $(CC) -o $(prom) $(obj)

%.o: %.c $(deps)
    $(CC) -c $< -o $@

clean:
    rm -rf $(obj) $(prom)

有了上面最后两行代码，当我们在终端中执行 make clean 命令时，它就会去删除该工程生成的所有编译文件。

另外，如果我们需要往工程中添加一个 .c 或 .h，可能同时就要再手动为 obj 常量再添加第一个 .o 文件，如果这列表很长，代码会非常难看，为此，我们需要用到Makefile中的函数，这里我们演示两个：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

cc = gcc
prom = calc
deps = $(shell find ./ -name "*.h")
src = $(shell find ./ -name "*.c")
obj = $(src:%.c=%.o) 

$(prom): $(obj)
    $(CC) -o $(prom) $(obj)

%.o: %.c $(deps)
    $(CC) -c $< -o $@

clean:
    rm -rf $(obj) $(prom)

其中，shell 函数主要用于执行shell命令，具体到这里就是找出当前目录下所有的 .c 和 .h 文件。而 $(src:%.c=%.o) 则是一个字符替换函数，它会将 src 所有的 .c 字串替换成 .o，实际上就等于列出了所有 .c 文件要编译的结果。有了这两个设定，无论我们今后在该工程加入多少 .c 和 .h 文件，Makefile都能自动将其纳入到工程中来。

到这里，我们就基本上将日常会用到的Makefile写法介绍了一遍。如果你想了解更多关于makefile和make的知识，请参考 GNU Make Manual。

原文地址：http://www.epubit.com.cn/article/546

原文地址：http://blog.youxu.info/2014/12/04/coroutine/

本文原发于《程序员》2014年11月刊，发表时略有修改。

计算机科学是一门应用科学，几乎所有概念都是为了理解或解决实际问题而生的。协程 (Coroutine) 的出现也不例外。协程的概念，最早可以追溯到写作 COBOL 语言编译器中的技术难题。

原文地址：https://segmentfault.com/a/1190000002715832
Posted by: 大CC | 28APR,2015
博客：blog.me115.com [订阅]
微博：新浪微博

平时接触的开源产品如Redis、ACE，事件模型都使用的Reactor模式；而同样做事件处理的Proactor，由于操作系统的原因，相关的开源产品也少；这里学习下其模型结构，重点对比下两者的异同点；

反应器Reactor

Reactor模式结构

任何版本控制系统的一个最有的用特性就是“撤销 (undo)”你的错误操作的能力。在 Git 里，“撤销” 蕴含了不少略有差别的功能。

当你进行一次新的提交的时候，Git 会保存你代码库在那个特定时间点的快照；之后，你可以利用 Git 返回到你的项目的一个早期版本。

在本篇博文里，我会讲解某些你需要“撤销”已做出的修改的常见场景，以及利用 Git 进行这些操作的最佳方法。

撤销一个“已公开”的改变

场景： 你已经执行了 git push, 把你的修改发送到了 GitHub，现在你意识到这些 commit 的其中一个是有问题的，你需要撤销那一个 commit.

方法： git revert <SHA>

原理： git revert 会产生一个新的 commit，它和指定 SHA 对应的 commit 是相反的（或者说是反转的）。如果原先的 commit 是“物质”，新的 commit 就是“反物质” — 任何从原先的 commit 里删除的内容会在新的 commit 里被加回去，任何在原先的 commit 里加入的内容会在新的 commit 里被删除。

这是 Git 最安全、最基本的撤销场景，因为它并不会改变历史 — 所以你现在可以 git push 新的“反转” commit 来抵消你错误提交的 commit。

修正最后一个 commit 消息

场景： 你在最后一条 commit 消息里有个笔误，已经执行了 git commit -m "Fxies bug #42"，但在 git push 之前你意识到消息应该是 "Fixes bug #42"。

方法： git commit --amend 或 git commit --amend -m "Fixes bug #42"

原理： git commit --amend 会用一个新的 commit 更新并替换最近的 commit ，这个新的 commit 会把任何修改内容和上一个 commit 的内容结合起来。如果当前没有提出任何修改，这个操作就只会把上次的 commit 消息重写一遍。

撤销“本地的”修改

场景： 一只猫从键盘上走过，无意中保存了修改，然后破坏了编辑器。不过，你还没有 commit 这些修改。你想要恢复被修改文件里的所有内容 — 就像上次 commit 的时候一模一样。

方法： git checkout -- <bad filename>

原理： git checkout 会把工作目录里的文件修改到 Git 之前记录的某个状态。你可以提供一个你想返回的分支名或特定 SHA ，或者在缺省情况下，Git 会认为你希望 checkout 的是 HEAD，当前 checkout 分支的最后一次 commit。

记住： 你用这种方法“撤销”的任何修改真的会完全消失。因为它们从来没有被提交过，所以之后 Git 也无法帮助我们恢复它们。你要确保自己了解你在这个操作里扔掉的东西是什么！（也许可以先利用 git diff 确认一下）

重置“本地的”修改

场景： 你在本地提交了一些东西（还没有 push），但是所有这些东西都很糟糕，你希望撤销前面的三次提交 — 就像它们从来没有发生过一样。

方法： git reset <last good SHA> 或 git reset --hard <last good SHA>

原理： git reset 会把你的代码库历史返回到指定的 SHA 状态。 这样就像是这些提交从来没有发生过。缺省情况下，git reset 会保留工作目录。这样，提交是没有了，但是修改内容还在磁盘上。这是一种安全的选择，但通常我们会希望一步就“撤销”提交以及修改内容 — 这就是 --hard 选项的功能。

在撤销“本地修改”之后再恢复

场景： 你提交了几个 commit，然后用 git reset --hard 撤销了这些修改（见上一段），接着你又意识到：你希望还原这些修改！

方法： git reflog 和 git reset 或 git checkout

原理： git reflog 对于恢复项目历史是一个超棒的资源。你可以恢复几乎 任何东西 — 任何你 commit 过的东西 — 只要通过 reflog。

你可能已经熟悉了 git log 命令，它会显示 commit 的列表。git reflog 也是类似的，不过它显示的是一个 HEAD 发生改变的时间列表.

一些注意事项：

• 它涉及的只是 HEAD 的改变。在你切换分支、用 git commit 进行提交、以及用 git reset 撤销 commit 时，HEAD 会改变，但当你用 git checkout -- <bad filename>撤销时（正如我们在前面讲到的情况），HEAD 并不会改变 — 如前所述，这些修改从来没有被提交过，因此 reflog 也无法帮助我们恢复它们。
• git reflog 不会永远保持。Git 会定期清理那些 “用不到的” 对象。不要指望几个月前的提交还一直躺在那里。
• 你的 reflog 就是你的，只是你的。你不能用 git reflog 来恢复另一个开发者没有 push 过的 commit。

那么…你怎么利用 reflog 来“恢复”之前“撤销”的 commit 呢？它取决于你想做到的到底是什么：

• 如果你希望准确地恢复项目的历史到某个时间点，用 git reset --hard <SHA>
• 如果你希望重建工作目录里的一个或多个文件，让它们恢复到某个时间点的状态，用 git checkout <SHA> -- <filename>
• 如果你希望把这些 commit 里的某一个重新提交到你的代码库里，用 git cherry-pick <SHA>

利用分支的另一种做法

场景： 你进行了一些提交，然后意识到你开始 check out 的是 master 分支。你希望这些提交进到另一个特性（feature）分支里。

方法： git branch feature, git reset --hard origin/master, and git checkout feature

原理： 你可能习惯了用 git checkout -b <name> 创建新的分支 — 这是创建新分支并马上 check out 的流行捷径 — 但是你不希望马上切换分支。这里， git branch feature 创建一个叫做 feature 的新分支并指向你最近的 commit，但还是让你 check out 在 master 分支上。

下一步，在提交任何新的 commit 之前，用 git reset --hard 把 master 分支倒回 origin/master 。不过别担心，那些 commit 还在 feature 分支里。

最后，用 git checkout 切换到新的 feature 分支，并且让你最近所有的工作成果都完好无损。

及时分支，省去繁琐

场景： 你在 master 分支的基础上创建了 feature 分支，但 master 分支已经滞后于 origin/master 很多。现在 master 分支已经和 origin/master 同步，你希望在 feature 上的提交是从现在开始，而不是也从滞后很多的地方开始。

方法： git checkout feature 和 git rebase master

原理： 要达到这个效果，你本来可以通过 git reset (不加 --hard, 这样可以在磁盘上保留修改) 和 git checkout -b <new branch name> 然后再重新提交修改，不过这样做的话，你就会失去提交历史。我们有更好的办法。

git rebase master 会做如下的事情：

• 首先它会找到你当前 check out 的分支和 master 分支的共同祖先。
• 然后它 reset 当前 check out 的分支到那个共同祖先，在一个临时保存区存放所有之前的提交。
• 然后它把当前 check out 的分支提到 master 的末尾部分，并从临时保存区重新把存放的 commit 提交到 master 分支的最后一个 commit 之后。

大量的撤销/恢复

场景： 你向某个方向开始实现一个特性，但是半路你意识到另一个方案更好。你已经进行了十几次提交，但你现在只需要其中的一部分。你希望其他不需要的提交统统消失。

方法： git rebase -i <earlier SHA>

原理： -i 参数让 rebase 进入“交互模式”。它开始类似于前面讨论的 rebase，但在重新进行任何提交之前，它会暂停下来并允许你详细地修改每个提交。

rebase -i 会打开你的缺省文本编辑器，里面列出候选的提交。如下所示：

前面两列是键：第一个是选定的命令，对应第二列里的 SHA 确定的 commit。缺省情况下， rebase -i 假定每个 commit 都要通过 pick 命令被运用。

要丢弃一个 commit，只要在编辑器里删除那一行就行了。如果你不再需要项目里的那几个错误的提交，你可以删除上例中的1、3、4行。

如果你需要保留 commit 的内容，而是对 commit 消息进行编辑，你可以使用 reword 命令。 把第一列里的 pick 替换为 reword (或者直接用 r)。有人会觉得在这里直接重写 commit 消息就行了，但是这样不管用 rebase -i 会忽略 SHA 列前面的任何东西。它后面的文本只是用来帮助我们记住 0835fe2 是干啥的。当你完成 rebase -i 的操作之后，你会被提示输入需要编写的任何 commit 消息。

如果你需要把两个 commit 合并到一起，你可以使用 squash 或 fixup 命令，如下所示：

squash 和 fixup 会“向上”合并 — 带有这两个命令的 commit 会被合并到它的前一个 commit 里。在这个例子里， 0835fe2 和 6943e85 会被合并成一个 commit， 38f5e4e 和 af67f82 会被合并成另一个。

如果你选择了 squash， Git 会提示我们给新合并的 commit 一个新的 commit 消息； fixup 则会把合并清单里第一个 commit 的消息直接给新合并的 commit 。 这里，你知道 af67f82 是一个“完了完了….” 的 commit，所以你会留着 38f5e4e as的 commit 消息，但你会给合并了 0835fe2 和 6943e85 的新 commit 编写一个新的消息。

在你保存并退出编辑器的时候，Git 会按从顶部到底部的顺序运用你的 commit。你可以通过在保存前修改 commit 顺序来改变运用的顺序。如果你愿意，你也可以通过如下安排把 af67f82 和 0835fe2 合并到一起：

修复更早期的 commit

场景： 你在一个更早期的 commit 里忘记了加入一个文件，如果更早的 commit 能包含这个忘记的文件就太棒了。你还没有 push，但这个 commit 不是最近的，所以你没法用 commit --amend.

方法： git commit --squash <SHA of the earlier commit> 和 git rebase --autosquash -i <even earlier SHA>

原理： git commit --squash 会创建一个新的 commit ，它带有一个 commit 消息，类似于 squash! Earlier commit。 (你也可以手工创建一个带有类似 commit 消息的 commit，但是 commit --squash 可以帮你省下输入的工作。)

如果你不想被提示为新合并的 commit 输入一条新的 commit 消息，你也可以利用 git commit --fixup 。在这个情况下，你很可能会用 commit --fixup ，因为你只是希望在 rebase 的时候使用早期 commit 的 commit 消息。

rebase --autosquash -i 会激活一个交互式的 rebase 编辑器，但是编辑器打开的时候，在 commit 清单里任何 squash 和 fixup 的 commit 都已经配对到目标 commit 上了，如下所示：

在使用 --squash 和 --fixup 的时候，你可能不记得想要修正的 commit 的 SHA 了— 只记得它是前面第 1 个或第 5 个 commit。你会发现 Git 的 ^ 和 ~ 操作符特别好用。HEAD^ 是 HEAD 的前一个 commit。 HEAD~4 是 HEAD 往前第 4 个 – 或者一起算，倒数第 5 个 commit。

停止追踪一个文件

场景： 你偶然把 application.log 加到代码库里了，现在每次你运行应用，Git 都会报告在 application.log 里有未提交的修改。你把 *.login 放到了 .gitignore 文件里，可文件还是在代码库里 — 你怎么才能告诉 Git “撤销” 对这个文件的追踪呢？

方法： git rm --cached application.log

原理： 虽然 .gitignore 会阻止 Git 追踪文件的修改，甚至不关注文件是否存在，但这只是针对那些以前从来没有追踪过的文件。一旦有个文件被加入并提交了，Git 就会持续关注该文件的改变。类似地，如果你利用 git add -f 来强制或覆盖了 .gitignore， Git 还会持续追踪改变的情况。之后你就不必用 -f 来添加这个文件了。

如果你希望从 Git 的追踪对象中删除那个本应忽略的文件， git rm --cached 会从追踪对象中删除它，但让文件在磁盘上保持原封不动。因为现在它已经被忽略了，你在 git status 里就不会再看见这个文件，也不会再偶然提交该文件的修改了。

这就是如何在 Git 里撤销任何操作的方法。要了解更多关于本文中用到的 Git 命令，请查看下面的有关文档：

• checkout
• commit
• rebase
• reflog
• reset
• revert
• rm

原文地址：https://github.com/blog/2019-how-to-undo-almost-anything-with-git
译文地址：http://blog.jobbole.com/87700/

共享内存可以说是最有用的进程间通信方式，也是最快的 IPC 形式, 因为进程可以直接读写内存，而不需要任何数据的拷贝。对于像管道和消息队列等通信方式，则需要在内核和用户空间进行四次的数据拷贝，而共享内存则只拷贝两次数据: 一次从输入文件到共享内存区，另一次从共享内存区到输出文件。实际上，进程之间在共享内存时，并不总是读写少量数据后就解除映射，有新的通信时，再重新建立共享内存区域。而是保持共享区域，直到通信完毕为止，这样，数据内容一直保存在共享内存中，并没有写回文件。共享内存中的内容往往是在解除映射时才写回文件的。因此，采用共享内存的通信方式效率是非常高的。

一、传统文件访问

UNIX访问文件的传统方法是用 open 打开它们, 如果有多个进程访问同一个文件，则每一个进程在自己的地址空间都包含有该文件的副本，这不必要地浪费了存储空间。下图说明了两个进程同时读一个文件的同一页的情形。系统要将该页从磁盘读到高速缓冲区中，每个进程再执行一个存储器内的复制操作将数据从高速缓冲区读到自己的地址空间。

二、共享存储映射

现在考虑另一种处理方法：进程 A 和进程 B 都将该页映射到自己的地址空间，当进程 A 第一次访问该页中的数据时，它生成一个缺页中断。内核此时读入这一页到内存并更新页表使之指向它。以后，当进程 B 访问同一页面而出现缺页中断时，该页已经在内存，内核只需要将进程 B 的页表登记项指向次页即可。如下图所示：

三、mmap() 及其相关系统调用

mmap() 系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以向访
问普通内存一样对文件进行访问，不必再调用 read()，write()等操作。

mmap() 系统调用形式如下：

1

void* mmap(void* addr, size_t len, int prot, int flags, int fd, off_t offset) 

mmap 的作用是映射文件描述符 fd 指定文件的 [off, off+len] 区域至调用进程的 [addr, addr+len] 的内存区域, 如下图所示:

参数 fd 为即将映射到进程空间的文件描述字，一般由 open() 返回，同时，fd 可以指定为 -1，此时须指定 flags 参数中的 MAP_ANON，表明进行的是匿名映射（不涉及具体的文件名，避免了文件的创建及打开，很显然只能用于具有亲缘关系的进程间通信）。
len 是映射到调用进程地址空间的字节数，它从被映射文件开头 offset 个字节开始算起。
prot 参数指定共享内存的访问权限。可取如下几个值的或：PROT_READ（可读），PROT_WRITE（可写），PROT_EXEC（可执行），PROT_NONE（不可访问）。
flags 由以下几个常值指定：MAP_SHARED, MAP_PRIVATE, MAP_FIXED，其中，MAP_SHARED, MAP_PRIVATE 必选其一，而 MAP_FIXED 则不推荐使用。
offset 参数一般设为 0，表示从文件头开始映射。
参数 addr 指定文件应被映射到进程空间的起始地址，一般被指定一个空指针，此时选择起始地址的任务留给内核来完成。函数的返回值为最后文件映射到进程空间的地址，进程可直接操作起始地址为该值的有效地址。

四、mmap的两个例子

范例中使用的测试文件 data.txt：

1
2
3
4

aaaaaaaaa
bbbbbbbbb
ccccccccc
ddddddddd

1. 通过共享映射的方式修改文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <error.h>

#define BUF_SIZE 100

int main(int argc, char **argv)
{
    int fd, nread, i;
    struct stat sb;
    char *mapped, buf[BUF_SIZE];

    for (i = 0; i < BUF_SIZE; i++) {
        buf[i] = '#';
    }

    /* 打开文件 */
    if ((fd = open(argv[1], O_RDWR)) < 0) {
        perror("open");
    }

    /* 获取文件的属性 */
    if ((fstat(fd, &sb)) == -1) {
        perror("fstat");
    }

    /* 将文件映射至进程的地址空间 */
    if ((mapped = (char *)mmap(NULL, sb.st_size, PROT_READ | 
                    PROT_WRITE, MAP_SHARED, fd, 0)) == (void *)-1) {
        perror("mmap");
    }

    /* 映射完后, 关闭文件也可以操纵内存 */
    close(fd);

    printf("%s", mapped);

    /* 修改一个字符,同步到磁盘文件 */
    mapped[20] = '9';
    if ((msync((void *)mapped, sb.st_size, MS_SYNC)) == -1) {
        perror("msync");
    }

    /* 释放存储映射区 */
    if ((munmap((void *)mapped, sb.st_size)) == -1) {
        perror("munmap");
    }

    return 0;
}

2. 私有映射无法修改文件

1
2
3
4
5

/* 将文件映射至进程的地址空间 */
if ((mapped = (char *)mmap(NULL, sb.st_size, PROT_READ | 
    PROT_WRITE, MAP_PRIVATE, fd, 0)) == (void *)-1) {
    perror("mmap");
}

五、使用共享映射实现两个进程之间的通信

两个程序映射同一个文件到自己的地址空间，进程 A 先运行, 每隔两秒读取映射区域，看是否发生变化。
进程 B 后运行，它修改映射区域，然后退出，此时进程 A 能够观察到存储映射区的变化。
进程 A 的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <error.h>

#define BUF_SIZE 100

int main(int argc, char **argv)
{
    int fd, nread, i;
    struct stat sb;
    char *mapped, buf[BUF_SIZE];

    for (i = 0; i < BUF_SIZE; i++) {
        buf[i] = '#';
    }

    /* 打开文件 */
    if ((fd = open(argv[1], O_RDWR)) < 0) {
        perror("open");
    }

    /* 获取文件的属性 */
    if ((fstat(fd, &sb)) == -1) {
        perror("fstat");
    }

    /* 将文件映射至进程的地址空间 */
    if ((mapped = (char *)mmap(NULL, sb.st_size, PROT_READ | 
                    PROT_WRITE, MAP_SHARED, fd, 0)) == (void *)-1) {
        perror("mmap");
    }

    /* 文件已在内存, 关闭文件也可以操纵内存 */
    close(fd);
    
    /* 每隔两秒查看存储映射区是否被修改 */
    while (1) {
        printf("%s\n", mapped);
        sleep(2);
    }

    return 0;
}

进程 B 的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

#include <sys/mman.h>  
#include <sys/stat.h>  
#include <fcntl.h>  
#include <stdio.h>  
#include <stdlib.h>  
#include <unistd.h>  
#include <error.h>  
  
#define BUF_SIZE 100  
  
int main(int argc, char **argv)  
{  
    int fd, nread, i;  
    struct stat sb;  
    char *mapped, buf[BUF_SIZE];  
  
    for (i = 0; i < BUF_SIZE; i++) {  
        buf[i] = '#';  
    }  
  
    /* 打开文件 */  
    if ((fd = open(argv[1], O_RDWR)) < 0) {  
        perror("open");  
    }  
  
    /* 获取文件的属性 */  
    if ((fstat(fd, &sb)) == -1) {  
        perror("fstat");  
    }  
  
    /* 私有文件映射将无法修改文件 */  
    if ((mapped = (char *)mmap(NULL, sb.st_size, PROT_READ |   
                    PROT_WRITE, MAP_PRIVATE, fd, 0)) == (void *)-1) {  
        perror("mmap");  
    }  
  
    /* 映射完后, 关闭文件也可以操纵内存 */  
    close(fd);  
  
    /* 修改一个字符 */  
    mapped[20] = '9';  
   
    return 0;  
}

六、通过匿名映射实现父子进程通信

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#include <sys/mman.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define BUF_SIZE 100

int main(int argc, char** argv)
{
    char    *p_map;

    /* 匿名映射,创建一块内存供父子进程通信 */
    p_map = (char *)mmap(NULL, BUF_SIZE, PROT_READ | PROT_WRITE,
            MAP_SHARED | MAP_ANONYMOUS, -1, 0);

    if(fork() == 0) {
        sleep(1);
        printf("child got a message: %s\n", p_map);
        sprintf(p_map, "%s", "hi, dad, this is son");
        munmap(p_map, BUF_SIZE); //实际上，进程终止时，会自动解除映射。
        exit(0);
    }

    sprintf(p_map, "%s", "hi, this is father");
    sleep(2);
    printf("parent got a message: %s\n", p_map);

    return 0;
}

七、对 mmap() 返回地址的访问

linux 采用的是页式管理机制。对于用 mmap() 映射普通文件来说，进程会在自己的地址空间新增一块空间，空间大小由 mmap() 的 len 参数指定，注意，进程并不一定能够对全部新增空间都能进行有效访问。进程能够访问的有效地址大小取决于文件被映射部分的大小。简单的说，能够容纳文件被映射部分大小的最少页面个数决定了进程从 mmap() 返回的地址开始，能够有效访问的地址空间大小。超过这个空间大小，内核会根据超过的严重程度返回发送不同的信号给进程。可用如下图示说明：

总结一下就是，文件大小，mmap 的参数 len 都不能决定进程能访问的大小，而是容纳文件被映射部分的最小页面数决定进程能访问的大小。下面看一个实例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main(int argc, char** argv)
{
    int fd,i;
    int pagesize,offset;
    char *p_map;
    struct stat sb;

    /* 取得page size */
    pagesize = sysconf(_SC_PAGESIZE);
    printf("pagesize is %d\n",pagesize);

    /* 打开文件 */
    fd = open(argv[1], O_RDWR, 00777);
    fstat(fd, &sb);
    printf("file size is %zd\n", (size_t)sb.st_size);

    offset = 0;    
    p_map = (char *)mmap(NULL, pagesize * 2, PROT_READ|PROT_WRITE, 
            MAP_SHARED, fd, offset);
    close(fd);
    
    p_map[sb.st_size] = '9';  /* 导致总线错误 */
    p_map[pagesize] = '9';    /* 导致段错误 */

    munmap(p_map, pagesize * 2);

    return 0;
}

原文地址：http://kenby.iteye.com/blog/1164700

闭包这个概念在 JavaScript 中讨论和使用得比较多，不过在 Python 中却不是那么显而易见，之所以说“不是那么”，是因为即使用到了，也没用注意到而已，比如定义一个 Decorator 时，就已经用到闭包了。网上对闭包的各种解释，感觉非常晦涩，在这里谈谈我的浅显认识：要形成闭包，首先得有一个嵌套的函数，即函数中定义了另一个函数，闭包则是一个集合，它包括了外部函数的局部变量，这些局部变量在外部函数返回后也继续存在，并能被内部函数引用。

举个例子

这是个经常使用到的例子，定义一个函数 generate_power_func，它返回另一个函数，现在闭包形成的条件已经达到。

1
2
3
4
5
6

def generate_power_func(n):
    print "id(n): %X" % id(n)
    def nth_power(x):
        return x**n
    print "id(nth_power): %X" % id(nth_power)
    return nth_power

对于内部函数 nth_power，它能引用到外部函数的局部变量 n，而且即使 generate_power_func 已经返回。把这种现象就称为闭包。具体使用一下。

1
2
3
4
5

>>> raised_to_4 = generate_power_func(4)
id(n): 246F770
id(nth_power): 2C090C8
>>> repr(raised_to_4)
'<function nth_power at 0x2c090c8>'

从结果可以看出，当 generate_power_func(4) 执行后, 创建和返回了 nth_power 这个函数对象，内存地址是 0x2C090C8,并且发现 raised_to_4 和它的内存地址相同，即 raised_to_4 只是这个函数对象的一个引用。先在全局命名空间中删除 generate_power_func，再试试会出现什么结果。

1
2
3

>>> del generate_power_func
>>> raised_to_4(2)
16

啊哈，居然没出现错误， nth_power 是怎么知道 n 的值是 4，而且现在 generate_power_func 甚至都不在这个命名空间了。对，这就是闭包的作用，外部函数的局部变量可以被内部函数引用，即使外部函数已经返回了。

closure 属性和 cell 对象

现在知道闭包是怎么一回事了，那就到看看闭包到底是怎么回事的时候了。Python 中函数也是对象，所以函数也有很多属性，和闭包相关的就是 __closure__ 属性。__closure__ 属性定义的是一个包含 cell 对象的元组，其中元组中的每一个 cell 对象用来保存作用域中变量的值。

1
2
3
4
5
6

>>> raised_to_4.__closure__
(<cell at 0x2bf4ec0: int object at 0x246f770>,)
>>> type(raised_to_4.__closure__[0])
<type 'cell'>
>>> raised_to_4.__closure__[0].cell_contents
4

就如刚才所说，在 raised_to_4 的 __closure__ 属性中有外部函数变量 n 的引用，通过内存地址可以发现，引用的都是同一个 n。如果没用形成闭包，则 __closure__ 属性为 None。对于 Python 具体是如何实现闭包的，可以查看 Python闭包详解，它通过分析 Python 字节码来讲述闭包的实现。

最后总结

闭包特性有着非常多的作用，不过都是需要时才会不经意的用上，不要像使用设计模式一样去硬套这些法则。这篇文章按照自己的理解翻译至 Python Closures Explained，可能和原文有些不同之处，如有疑惑，请查看原文。附上一些参考资料。

1. 闭包的概念、形式与应用: 可以从其中了解闭包的应用
2. Python闭包详解：从字节码出发了解 Python 闭包的实现机制
3. 理解Javascript的闭包: 从 Javascript 的闭包中了解一些闭包特性，可以和 Python 作下对比

原文地址：https://serholiu.com/python-closures

首先说说系统环境，Windows 7 64 位系统，PowerDesigner 16.5，远程 PostgreSQL 9.4 数据库，JDK 为 64 位的 Java 8。

笔者依次点击：

Database->Configure Connections...->Connection Profiles->Add Datasource

输入以下配置：

1
2
3
4

Connection type: JDBC
DBMS type: PostgreSQL
JDBC driver class: org.postgresql.Driver
JDBC connection URL: jdbc:postgresql://<your_host>:5432/<your_database>

但是点击 Test connection 时出现了问题。

Could not Initialize JavaVM!

原因分析

这个原因很简单，笔者安装的是 64 位的 JDK 和 JRE，而 Power Designer 是 32 位的，其 JDBC 无法在 64 位的 Java 虚拟机上运行。

解决

从 Oracle 官网上下载 32 位的 JDK，安装时不要自动配置环境变量，因为笔者系统里的其他程序还要运行在 64 位虚拟机上，能不能只让 Power Designer 在 32 位虚拟机上运行呢？下一步将完美解决这个问题。

Non SQL Error : Could not load class org.postgresql.Driver

原因分析

原因是找不到 PostgreSQL 的 Java 驱动。

解决

访问 http://jdbc.postgresql.org/download.html，下载对应的 jar 包（笔者下载的是 postgresql-9.4.1208.jar）。

将下载下来的 jar 包放入某个目录，笔者放在了 D:\Tools\Sybase\PowerDesigner 16\SQL Anywhere 12 drivers 这个目录，当然你可以放到任意目录。

然后在 Power Designer 安装目录新建一个 PowerDesigner.bat 文件，输入以下内容：

1
2
3
4
5

set JAVA_HOME="C:\Program Files (x86)\Java\jdk1.8.0_77"
set CLASSPATH="%JAVA_HOME%\lib\jt.jar;%JAVA_HOME%\lib\tools.jar;D:\Tools\Sybase\PowerDesigner 16\SQL Anywhere 12 drivers\postgresql-9.4.1208.jar"
cd "D:\Tools\Sybase\PowerDesigner 16"
start /b PdShell16.exe
exit

其中 JAVA_HOME 是上一步安装的 32 位 JDK 的目录，CLASSPATH 包含那个 postgresql 的 Java 驱动 jar 包。

保存后，右键发送到桌面快捷方式即可，也可以给它换个图标，以后运行时双击这个快捷方式就可以了。

Unable to list the columns. SQLSTATE = 22003不良的类型值 short : t

然而成功连接数据库后建模时出现了“不良的类型值问题”，解决方法如下：

依次点击

Database->Edit Current DBMS...->General Tab->PostgreSQL 9.x->Script->Objects

或者

Tools->Edit Current DBMS->PostgreSQL 9.x->Script->Objects

将 Column->SqlListQuery 选项里 SELECT 中的 c.attnotnull 替换为 cast(nullif(c.attnotnull, false) as varchar(1))

将 Key->SqlListQuery 选项里 SELECT 中的 x.indisprimary 替换为 cast(nullif(x.indisprimary, false) as varchar(1))

保存即可。

参考文章：

• 用PowerDesigner远程连接PostgreSQL数据库
• PowerDesigner 16.5 反向PostgreSQL9.01 中 Unable to list the columns. SQLSTATE = 22003不良的类型值 short : t 解决方法