看了下第一次作業，那個排版和高亮背景有點瞎，這次能好點就不錯了.
第二章是關于POSIX以及XSI的一些標準和limitation，就不做作業了，直接到第三章，沒有睡午覺，有些困，不要寫錯...
先貼一些比較好的思路
(1)在AF_LOCAL(Posix: AF_UNIX)的Socket編程中，對Client端來說需要connect
int connect(int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen)
這里需要給serv_addr一個length，這個length是一個真實的地址長度。
當socket為AF_UNIX的Socket時 socket address為sockaddr_un里面存放著地址類型以及socket path，我們需要知道sockaddr_un中真正存放數據的長度。
函數offsetof是不錯的選擇
這個function的實現看起來可以學習，我先抄一段貼下面
#define offsetof(TYPE, MEMBER) ((size_t) & ((TYPE *)0)->MEMBER )
宏功能：獲得一個結構體變量成員在此結構體中的偏移量。
1. ( (TYPE *)0 ) 將零轉型為TYPE類型指針;
2. ((TYPE *)0)->MEMBER 訪問結構中的數據成員;
3. &( ( (TYPE *)0 )->MEMBER )取出數據成員的地址，即相對于0的偏移量，要的就這個;
4.(size_t)(&(((TYPE*)0)->MEMBER))結果轉換類型，size_t應該最終為unsigned int類型。
此宏的巧妙之處在于將 0 轉換成(TYPE*)，這樣結構體中成員的地址即為在此結構體中的偏移量。
這里主要還是利用了 '->' 這個符號的功能，編譯器解析這個符號的時候應該就是通過偏移量取值，所以這里先定義好取值規則(TYPE*)然后利用偏移量取值反向再取地址，再然后因為起始地址是0，取回的地址就變成了真正的偏移量。
還有一個知道member求整體的Ptr的Marco應該也蠻好用，括號比較多，我沒頭去看具體實現了...
#define container_of(ptr, type, member) ({ \
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
(type *)( (char *)__mptr – offsetof(type,member) );})
宏功能：從結構體（type）某成員變量（member）指針（ptr）來求出該結構體（type）的首指針。
(2)
有討論一些東西，沒有搞清楚，貼在這里以后有心力了再看，在看Rild，然后pthread在做線程同步的時候需要先lock，也許大家都是這樣做，也一直這樣做，但是突然就想到之前Java的時候討論過的東西為什么wait/notify 一定要在一個synchronize block中，當然你可以講，如果不會有exception拋出，你也還可以講wait本來就會先釋放lock然后把當前的thread放到Object waiting thread pool中然后掛起當前線程，實現就是這樣子，但是從設計來講，原因我沒有想的特別清楚，如果不去lock，是不是因為wait/notify本身有很多操作沒辦法做multi thread...
然后就是關于select的一些輔助的Marco，類似FD_SET，FD_ZERO之類的，簡單講就是一個long數組，每個元素的每個bit代表一個fd，然后做set，clear之類的動作，最大不能超過那個1024
今天先到這里，寫個序，明天正文...Orz
(3)
繼續討論東西
有人為了在C++中作出類似Java可以自動釋放內存的東西，也就是所謂的智能指針，Android有幫忙實現strong pointer/weak pointer，他的大概意思就是用一個第三者來看住當前new出來的object，采用的方式一般是引用計數，這種方式也許在Design Pattern中有專門的名字。一般利用編譯器對這個第三者做自動釋放的時候去檢查計數器，看是否能釋放他看管的object，C++里面編譯器會自動去call ~Constructor就例如局部變量。
有一些復雜的Case，就算是交叉引用了，Strong Pointer/Weak Pointer就是為了解決交叉引用的問題，從語義上講父Object引用子Object，用SP，反過來用WP
只要SP為0，就可以釋放Memory
今天大家有講Java的WeakReference，SoftReference，我就含糊了，我以為這東西和上面一樣。
Java的WeakReference，SoftReference跟上面講的完全不一樣，由于沒分清楚，混淆了。JVM就會處理引用交叉的問題，JVM處理引用交叉可以使用類似有向圖，如果呈環狀而且環中的任意點都沒辦法到GC Roots(VM stack中的Reference/static reference/JNI reference)，那么就都GC掉應該也沒問題。
所以Java中的所謂的WeakReference/SoftReference跟SP/WP不一樣，Java中普通賦值的reference都是強可及的Strong Reference。
WeakReference只是用來關心下那些將要被回收卻沒有回收的Object，一旦被GC Thread掃到就會被釋放。
而SoftReference是JVM對Object的Cache，只要內存足夠不會被釋放。
貼一個講Android SP/WP的鏈接，之前有印象看過。
http://blog.csdn.net/luoshengyang/article/details/6786239
(4)
Keep Thinking...
某人讓我寫一個處理字符串的函數，30min， 我怎么也不能讓他失望的，是吧~無論11點多的時候我頭有多暈，我很開心的在那里寫，很直白的講，我自己用的本是個游戲機，沒啥好環境。用C寫了個，然后跑出來的結果出乎預料，我想可能是長時間指手畫腳慣了~仔細想了下一些文件操作
然后仔細看了一下二進制文件和文本文件，這也是糾正之前的一些疑惑。
基本概念是:
我自己感覺文本文件和二進制文件沒啥區別，文本文件就是有明確普通解碼方式的顯示字符的文件，可以理解說文本文件也是一種二進制文件，只不過這個二進制文件的解碼方式是固定好的(ASCII/UTF-8之類)
然后就是讀寫文本文件時在Windows上有一些轉換，寫的時候會在\n前面自動加上\r，讀的時候反過來，Linux則沒有區別。
有一件事情是要明確知道的
像printf之類的東西，幫助我們輸出的，其實我們往printf里面塞的是 int 值，這是一個二進制的值，但是我們從stdout中看到的則已經變成了字符，一定有人幫忙做了轉換.
我原本以為printf會是檢查目標文件，如果目標文件為二進制則直接輸出原本的值，如果目標為文本文件就輸出對應值的字符
這種理解是錯的，不同的輸入輸出函數帶來了不同的結果
類似printf這種格式話輸出函數，會把輸出內容按照字符以默認的編碼方式encode放入文件，所以那個文件里面寫的值已經是真實值的一種顯示方式(字符)了
然后scanf這種函數在讀的之后，也會把字符轉換為對應的值，一般ASCII就直接 -0x30了
像read/write這種function他們不會做任何轉換，直接就把值放進去了，所以你用文本文件打開的時候，按照默認的decode方式來解析他的時候會發現是亂碼。
這個東西與文本文件二進制文件沒有關系。
不知道是不是我自己很弱，現在才知道這個東西。
作業終于開始:
3.1 這章主要講文件Unbuffered IO，這里的unbuffered是指userspace沒有buffer來緩沖，kernel一定還是有緩沖的，一般userspace的緩沖做在標準C lib中
另外像Android這種架構Java layer會做緩沖(BufferedInputStream/BufferedOutputStream, 默認是8K)
Java layer的緩沖可以減少 JNI 調用次數
C lib緩沖可以減少 system call 的次數
3.2 自己實現dup2
不能用fcntl那就只能用dup了
這里是想要讓做題的人知道，kernel對進程文件描述符的分配原則是 "取最小的沒有使用的"
所以用dup實現Mydup(fd1, fd2)
1.fd2 < fd1: close fd2; dup(fd1)得到的值就是fd2
2.fd2 = fd1: 直接return fd1
3.fd2 > fd1: 那就只能無限dup了，直到返回值為fd2，然后close掉 fd1 ~ fd2-1
這里需要對文件描述符表，文件表，inode之類的概念熟悉。
3.3
這里主要是要說文件表項的分配，每次open kernel都會分配新的文件表項，dup的作用就是拿到另外一個文件描述符指向相同的文件表項，但是每支文件只有同一份
inode。
fd1，fd2會指向同一份文件表項
fd1，fd2，fd3的文件表項會指向同一份inode
fcntl 作用于fd1，F_SETFD用來設定 close_on_exec 標志這個東西是在文件描述符中的，所以只會影響fd1
如果是F_SETFL則會影響fd1, fd2文件狀態標志都放在文件表中。
3.4
dup2(fd, 0);
dup2(fd, 1);
dup2(fd, 2);
if (fd > 2) close(fd);
這個東西的作用應該就是重定向標準輸入輸出和錯誤輸出到fd.
3.5
沒什么重要的，shell命令一定是從左往右解析執行的
3.6
雖然是append方式打開，這個東西是針對寫，lseek可以自己選定讀取位置。
write函數是否是會每次先lseek到文件尾部?然后再寫，這樣之前lseek的設置就無效了
小東西驗證。
后面貼下代碼
append會影響每次write，只要是O_APPEND打開，每次write都會添加到文件末尾。
Done