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