其他

“同步”和“非同步”這兩個概念強調的是I/O操作在返回之前是否需要等待某個時間，而“同步化”強調的是必鬚髮生何種事件。比如寫入操作的四種情況如下：“同步化”+“同步”：操作會等到資料被刷入磁碟後返回，比如檔案以O_SYNC模式開啟；“同步化”+“非同步”：雖然操作會在請求插入隊列的時候就返回，但是該操作會保證資料刷入磁碟“非同步化”+“同步”：資料寫入核心緩衝中才返回，但是該操作只會影響核心緩衝區，這是通常方式；“非同步化”+“非同步”：操作插入請求隊列就馬上返回了。為什麼會需要非同步I/O操作

文章目錄 1、請求調頁2、寫時複製 在剛開始看的時候感覺缺頁異常（這可是異常啊，搞Java的人表示對著個比較敏感）肯定是一些進程在搞鬼，看完才發現原來是核心在搞鬼，它是故意的！！！1、請求調頁   

1、ext2_add_link的執行過程，函數的定義如下：int ext2_add_link (struct dentry *dentry, struct inode *inode){struct inode *dir = dentry->d_parent->d_inode;//父節點的inode const char *name = dentry->d_name.name;//目錄名 int namelen =

在“庫”之類的程式的設計中，只有部分的代碼是公布給使用者的。可以通過存取權限的控制來實現。“庫”是由一個一個的“包”組成的，用“package”打包（這句話必須在非注釋的第一行），而使用者用“import”引入就可以了。在封裝包的時候用反過來的網域名稱的唯一的標誌一個包（因為網域名稱是唯一的，所以所發行的包名也是唯一的）。Java解譯器在執行的時候，先找到“CLASSPATH”，以此為根目錄開始找“.class”檔案。Java中的“存取控制符”只有一個是比較特別的：如果一個變數前面什麼都不寫（也

　　以前對壓縮演算法一無所知，只是知道哈弗曼編碼能做這種事情，但是感覺這樣的方法奇慢無比。昨天下午看了下號稱世界上最快的壓縮演算法Quicklz，對壓縮的基本思路有了一定的瞭解。一般的壓縮程式的要求讀入檔案之後以便壓縮一邊輸出，而不是去先分析整個檔案中的情況之後才做決定採取哪種演算法。　　Quicklz也不例外也是爭取利用檔案中重複出現的位元組來進行壓縮，管理結構如下：在壓縮的過程中不斷地讀入3個位元組，然後根據這3個位元組得到一個hash值，根據這個hash值就可以找到offset，這個off

#include <stdio.h>#include <unistd.h>#include <sys/poll.h>int main(void){//要等待的檔案的數組 struct pollfd fds[2];int ret; fds[0].fd = STDIN_FILENO;//檔案符 fds[0].events = POLLIN;//等待的事件類型 fds[1].fd = STDOUT_FILENO;

很久之前看過一個題目，當時沒在意，昨天早上突然想起來，記錄一下。題目的大概意思是：兩男兩女，各有不同性病，現只有兩個安全套，要求每個男的都和每個女的發生性關係，且不互相傳染病。問如何使用安全套？至於這個是不是哈佛的題目就不管了，現在也沒想到更好的描述方法。就這個題目本身來說是很簡單的，下面是解法（N代表男生，V代表女生）：N1--T1+T2--V1（兩個TT和在一起用）；N1--T1--V2；N2--T2--V1；N2--T2+T1--V1（兩個TT和在一起用）。     

epoll使得時間監聽器的註冊與實際的事件監視工作脫鉤，有三種系統調用：初始化epoll的上下文；將要查看的檔案描述符加入上下文（或移除）；實際執行時間等待。#include <stdio.h>#include <fcntl.h>#include <string.h>#include <unistd.h>#include <sys/types.h>#include <sys/stat.h>#include

#include <stdio.h>#include <sys/time.h>#include <sys/types.h>#include <unistd.h>int main(void){struct timeval tv; fd_set readfds;int ret;//等待stdin的輸入 FD_ZERO(&readfds);//移除所有 FD_SET(STDIN_FILENO,

    很久沒有寫東西了，這幾天看了下以前看過的東西，然後下午看了下核心中PST的實現。因為在網上很少，也找不到什麼權威的分析，所以這裡的分析也不能保證是完全正確的。先看相關的結構體：下面是PST的根：struct prio_tree_root {struct prio_tree_node *prio_tree_node; unsigned short index_bits; unsigned short

先看相關的變數的意思：enum km_type {D(0) KM_BOUNCE_READ,D(1) KM_SKB_SUNRPC_DATA,D(2) KM_SKB_DATA_SOFTIRQ,D(3) KM_USER0,D(4) KM_USER1,D(5) KM_BIO_SRC_IRQ,D(6) KM_BIO_DST_IRQ,D(7) KM_PTE0,D(8) KM_PTE1,D(9) KM_IRQ0,D(10) KM_IRQ1,D(1

與進程相關的使用者ID有四個：真實的、有效、被儲存的、檔案系統的使用者ID。真實的ID是指啟動進程的使用者的ID。有效使用者ID是指正在啟動並執行進程的使用者ID。被儲存的ID是進程最初的有效使用者ID。有效使用者ID最重要，是確認進程憑證期間所檢查的使用者ID，真實ID和被儲存的ID可作為替代品。root使用者可以給uid提供任何值，但是普通使用者只能提供真實ID或者被儲存的使用者ID。下面是和各種ID相關的方法，不詳細：int main(){ printf("uid:%d\n",

在縮放和截取圖片的時候會發現在處理有透明效果的png圖片是會出現意想不到的效果，莫名奇妙出來很多黑線。因為在很多的圖片格式中是沒有透明效果的，所以在解析的時候就會出錯。alpha通道是指一張圖片的透明和半透明，比如一個使用16位中繼存放區的位元影像，對於圖形中的每一個像素而言，可能以一個5個位元表示紅色，5個綠色，5個藍色，最後一個位元是alpha。在這種情況下，它要麼表示透明要麼不是。如果是用32個位中繼存放區的位元影像，紅綠藍分別用8位，剩下的8位用來表示不同程度的透明度。在處理的時候，如果

#include <stdio.h>int main(){ FILE* file;char buf[1024], ch; file = fopen("test", "r+");//開啟檔案//設定緩衝 setvbuf(file, buf, _IOFBF, sizeof(buf)); fgets(buf, sizeof(buf), file);//讀取一整行 ch = fgetc(file);//讀取單個字元 ungetc(ch,

    在進入正題之前先看看vmalloc是怎麼申請記憶體的（雖然在前面的文章中已經說過了）。管理vmalloc分配空間用到的資料結構是vm_struct。首先用slab分配一個vm_struct執行個體，然後從vm_struct鏈表中找到一個合適的位置準備插入這個執行個體。這個執行個體只是用來管理這塊記憶體的，那下面就開始申請這些記憶體，也就是一頁一頁地從buddy

普通檔案的讀寫操作，範例如下：#include <stdio.h>#include <fcntl.h>#include <unistd.h>#include <stdlib.h>#include <sys/stat.h>int main(){char buf[10];int n, fd;struct stat file_stat; stat("test", &file_stat);

       memlink按照天涯的人說是一個灰常牛的key-List系統，比Redis要快很多倍，下面就來一點點看它的代碼。在記憶體中的Block也是通過一個池來管理的，用到的資料結構大致有三個DataBlock、MemItem、MemPool。MemPool的結構如下：typedef struct _mempool{ MemItem *freemem; // 數組 int size;     // 數組的大小 int used;

include <stdio.h>#include <fcntl.h>#include <string.h>#include <unistd.h>#include <sys/types.h>#include <sys/stat.h>#include <sys/uio.h>int main(){int fd = open("test", O_RDWR);char *buf[] =

1、讓出處理器　　Linux提供一個系統調用運行進程主動讓出執行權：sched_yield。進程啟動並執行好好的，為什麼需要這個函數呢？有一種情況是使用者空間線程的鎖定。如果一個線程試圖取得另一個線程所持有的鎖，則新的線程應該讓出處理器知道該鎖變為可用。使用者空間鎖沒有核心的支援，這是一個最間單、最有效率的做法。但是現在Linux線程實現引入一個使用futexes的最佳化解決方案。　　另一個情況是在有處理器密集型程式可用周期性調用sched_yield，試圖將該進程對系統的衝擊減到最小。不管怎麼

在網上看了一些解決的方法，試了下沒解決問題。首先要明白為什麼會出現這種問題：FileItem中用的編碼方式是UTF-8，而工程用的編碼方式是GBK。在Debug的時候看發現傳進來的檔案名稱已經是亂碼了，過來的位元組數群組轉換成GBK的原因，所以現在要用GBK來讀該串：fileItem.getName().getBytes("GBK") 讀完之後要把它還原成正確的格式，也就是UTF-8：new String(fileItem.getName().getBytes("GBK"), "UTF-8")