文章是在網上搜到的，我只是截取了其中一段。
#define?_GNU_SOURCE?/*?needed?to?get?the?defines?*/?
#include?/**//*?in?glibc?2.2?this?has?the?needed?
values?defined?*/?
#include?
#include?
#include?
static?volatile?int?event_fd;?
//?信號處理例程?
static?void?handler(int?sig,?siginfo_t?*si,?void?*data)?
{?
event_fd?=?si->si_fd;?
}?
int?main(void)?
{?
struct?sigaction?act;?
int?fd;?
//?登記信號處理例程?
act.sa_sigaction?=?handler;?
sigemptyset(&act.sa_mask);?
act.sa_flags?=?SA_SIGINFO;?
sigaction(SIGRTMIN,?&act,?NULL);?
//?需要了解當前目錄"."的情況?
fd?=?open(".",?O_RDONLY);?
fcntl(fd,?F_SETSIG,?SIGRTMIN);?
fcntl(fd,?F_NOTIFY,?DN_MODIFY|DN_CREATE|DN_MULTISHOT);?
/**//*?we?will?now?be?notified?if?any?of?the?files?
in?"."?is?modified?or?new?files?are?created?*/?
while?(1)?{?
//?收到信號后，就會執(zhí)行信號處理例程。?
//?而?pause()?也就結束了。?
pause();?
printf("Got?event?on?fd=%d\n",?event_fd);?
}?
}?
上面這一小段例程，對于熟悉 Linux 系統(tǒng)編程的讀者朋友們來說，是很容易理解的。程序首先注冊一個信號處理例程，然后通知 Kernel，我要觀察 fd 上的 DN_MODIFY 和 DN_CREATE 和 DN_MULTISHOT 事件。（關于這些事件的詳細定義，請讀者朋友們參閱文后所列的參考資料。） Linux Kernel 收到這個請求后，把相應的 fd 的 inode 給做上記號，然后 Linux Kernel 和用戶應用程序就自顧自去處理各自的別的事情去了。等到 inode 上發(fā)生了相應的事件，Linux Kernel 就把信號發(fā)給用戶進程，于是開始執(zhí)行信號處理例程，用戶程序對文件系統(tǒng)上的變化也就可以及時的做出反應了。而在這整個過程中，系統(tǒng)以及用戶程序的正常運行基本上未受到性能上的影響。這里還需要說明的是，dnotify 并沒有通過增加新的系統(tǒng)調用來完成它的功能，而是通過 fcntl 來完成任務的。增加一個系統(tǒng)調用，相對來說是一個很大的手術，而且如果設計不當，處理得不好的話，傷疤會一直留在那里，這是 Linux Kernel 的開發(fā)者們所非常不愿意見到的事情。
?