• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            T9的空間

            You will never walk alone!

              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              69 隨筆 :: 0 文章 :: 28 評論 :: 0 Trackbacks

            13章在講Daemon Process,沒什么特別好寫的。
            14 ->高級IO

            低速系統(tǒng)調(diào)用,也就是有信號發(fā)生會返回 errno 為 EINTR的

            磁盤文件IO雖然有延時,但是這個不能算是低速系統(tǒng)調(diào)用

            APUE介紹的低速系統(tǒng)調(diào)用
            PIPE,終端設(shè)備,網(wǎng)絡(luò)設(shè)備 讀寫
            讀無數(shù)據(jù)/寫無空間(例如TCP卡Congestion window)

            打開某些特殊文件
            加記錄鎖的文件讀寫
            ioctl,IPC


            文件鎖又叫做 byte-range locking,針對特定的文件區(qū)域,適合數(shù)據(jù)庫文件
            Posix標準
            int fcntl(int fd, int cmd, .../* struct flock* flockptr */)
            cmd -> F_GETLK,F_SETLK,F_SETLKW
            F_SETLKW是F_SETLK的Blocking版本 W means wait

            重要數(shù)據(jù)結(jié)構(gòu)是struct flock ->
            struct flock {
             short l_type;
             short l_whence;
             off_t l_start;
             off_t l_len;
             pid_t l_pid;
             __ARCH_FLOCK_PAD
            };

            鎖定整個file的方式: l_whence = SEEK_SET, l_start = 0, l_len = 0

            l_type的兩類lock
            F_RDLCK,F(xiàn)_WRLCK這兩種鎖的特性很像rw lock

            不過與讀寫鎖不一樣的是或者這樣講
            Posix.1沒有規(guī)定下面這種情況: process A在某文件區(qū)間上設(shè)置了一把讀鎖;process B嘗試在這個文件區(qū)間加上寫鎖的時候suspend;process C再嘗試獲取讀鎖,如果允許

            process C拿到讀鎖,那么process B將會可能永遠拿不到寫鎖,活活餓死

            pthread里面的rw lock的實現(xiàn)會在這種情況下suspend掉process C的讀鎖請求;但是目前文件區(qū)域鎖的實現(xiàn)我不太確定

            這里看文件區(qū)域鎖還是比較容易帶來deadlock的
            例如process A鎖住F1的某個區(qū)域,然后去鎖F2的一個區(qū)域,這時候F2的這個區(qū)域被process B鎖住,那么process A就會suspend,如果這個時候process B過來要鎖F1的這個區(qū)域
            就會發(fā)生deadlock


            關(guān)于文件區(qū)域鎖的繼承和釋放
            1.fork后,文件區(qū)域鎖并不繼承,繼承了就完了,不同的process就有可能同時干同一件事情,把數(shù)據(jù)搞壞
            2.close(fd)后 fd對應的文件鎖就被釋放了,文件鎖掛在inode上,close的時候kernel會去掃描對應的inode上與這個PID相關(guān)的lock,釋放掉,而并不去關(guān)心是哪個文件描述符或

            者是哪個文件表,這很重要,因為lockf中并不記錄fd,他們只是弱關(guān)聯(lián)關(guān)系,這個很重要。
            3.exec后,文件鎖會繼承原來執(zhí)行程序的鎖(fork之后拿到的lock),如果fd帶有close-on-exec那么根據(jù)第二條,這個fd對應的file上的鎖都會被釋放。


            后面講了STREAMS,感覺linux上用到的不多,需要在編譯kernel時動態(tài)加載

            IO多路轉(zhuǎn)接,主要是為了實現(xiàn)polling既所謂的輪詢
            主要函數(shù)有select,pselect,poll,epoll
            select也會算是低速系統(tǒng)調(diào)用,那么就有可能被信號打斷
            pselect有參數(shù)可以設(shè)定信號屏蔽集,也提供更高精度的timer

            poll的方式與select有不太一樣的地方,但是功能相同,epoll更適合大數(shù)據(jù)量。

            readv和writev
            記住下面兩條就夠了
            一個稱為scatter read(散步讀);另外一個稱為gather write(聚集寫)
            這兩個函數(shù)會面對一個buffer鏈表。


            readn和writen
            這個比較像現(xiàn)在Android里面socket的read和write方式,保證能read/write n byte數(shù)據(jù),在內(nèi)部做循環(huán)
            我比較好奇這兩個是否會處理signal,想來應該是會處理的,遇到EINTR幫忙重啟就好了

            我沒有找到Bionic庫的實現(xiàn)


            存儲映射IO
            這個很重要,mmap用的很多,映射到process空間的位置在 stack以下,heap以上的部分,map完后返回低地址。

            #include<sys/mman.h>
            void* mmap(void* addr, size_t len, int prot, int flag, int filedes, off_t off)

            prot -> PROT_READ,PROT_WRITE,PROT_EXEC,PROT_NONE
            prot指定的對映射存儲區(qū)的保護不能超過文件的open權(quán)限

            在 flag為 MAP_FIXED的時候OS會保證分配的memory起始地址為addr,否則只是給OS一個建議。
            一般建議addr給0,讓OS來決定。

            MAP_SHARED是說對映射區(qū)域的存儲(write)會導致修改該文件。
            MAP_PRIVATE則是對映射區(qū)域的操作會常見一個映射文件的副本。


            后面有個例子用了lseek
            使用lseek增加文件長度的方式,先lseek一個值,如果這個值大于文件本身的長度,那么下一次寫就會加長該文件,并且在文件
            中形成一個空洞,未寫過的內(nèi)容全部讀為0。
            mmap只能map文件的最大長度,超過的地方?jīng)]辦法同步到文件。

            posted on 2013-06-05 16:59 Torres 閱讀(328) 評論(0)  編輯 收藏 引用 所屬分類: APUE
            久久夜色精品国产www| 久久99精品免费一区二区| 久久精品国产亚洲AV不卡| 少妇无套内谢久久久久| 无码人妻久久久一区二区三区| 丰满少妇高潮惨叫久久久| 久久久精品久久久久久 | 精品久久8x国产免费观看| 久久精品国产福利国产秒| 久久影院亚洲一区| 久久婷婷激情综合色综合俺也去| 日本精品久久久久中文字幕8| 亚洲AⅤ优女AV综合久久久| 久久久精品人妻一区二区三区蜜桃 | 久久精品夜色噜噜亚洲A∨| 久久久久久国产精品美女| 99久久中文字幕| 亚洲精品乱码久久久久久蜜桃图片| 国产—久久香蕉国产线看观看| 久久天天躁夜夜躁狠狠| 久久这里只有精品视频99| 国产精品久久久久无码av| 久久久久久精品免费看SSS| 青青久久精品国产免费看| 99久久国产免费福利| 国内精品九九久久久精品| 亚洲AV无码久久| 久久夜色精品国产噜噜噜亚洲AV | 热久久视久久精品18| 91精品观看91久久久久久| MM131亚洲国产美女久久| 午夜欧美精品久久久久久久| 久久99热这里只频精品6| 性高朝久久久久久久久久| 久久久久亚洲AV成人网人人网站| 91精品久久久久久无码| 久久综合综合久久狠狠狠97色88 | 伊人色综合久久天天网| 一级女性全黄久久生活片免费 | 美女久久久久久| 亚洲欧洲久久久精品|