文章是在網(wǎng)上搜到的，我只是截取了其中一段。
#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;?
//?信號(hào)處理例程?
static?void?handler(int?sig,?siginfo_t?*si,?void?*data)?
{?
event_fd?=?si->si_fd;?
}?
int?main(void)?
{?
struct?sigaction?act;?
int?fd;?
//?登記信號(hào)處理例程?
act.sa_sigaction?=?handler;?
sigemptyset(&act.sa_mask);?
act.sa_flags?=?SA_SIGINFO;?
sigaction(SIGRTMIN,?&act,?NULL);?
//?需要了解當(dāng)前目錄"."的情況?
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)?{?
//?收到信號(hào)后，就會(huì)執(zhí)行信號(hào)處理例程。?
//?而?pause()?也就結(jié)束了。?
pause();?
printf("Got?event?on?fd=%d\n",?event_fd);?
}?
}?
上面這一小段例程，對(duì)于熟悉 Linux 系統(tǒng)編程的讀者朋友們來說，是很容易理解的。程序首先注冊(cè)一個(gè)信號(hào)處理例程，然后通知 Kernel，我要觀察 fd 上的 DN_MODIFY 和 DN_CREATE 和 DN_MULTISHOT 事件。（關(guān)于這些事件的詳細(xì)定義，請(qǐng)讀者朋友們參閱文后所列的參考資料。） Linux Kernel 收到這個(gè)請(qǐng)求后，把相應(yīng)的 fd 的 inode 給做上記號(hào)，然后 Linux Kernel 和用戶應(yīng)用程序就自顧自去處理各自的別的事情去了。等到 inode 上發(fā)生了相應(yīng)的事件，Linux Kernel 就把信號(hào)發(fā)給用戶進(jìn)程，于是開始執(zhí)行信號(hào)處理例程，用戶程序?qū)ξ募到y(tǒng)上的變化也就可以及時(shí)的做出反應(yīng)了。而在這整個(gè)過程中，系統(tǒng)以及用戶程序的正常運(yùn)行基本上未受到性能上的影響。這里還需要說明的是，dnotify 并沒有通過增加新的系統(tǒng)調(diào)用來完成它的功能，而是通過 fcntl 來完成任務(wù)的。增加一個(gè)系統(tǒng)調(diào)用，相對(duì)來說是一個(gè)很大的手術(shù)，而且如果設(shè)計(jì)不當(dāng)，處理得不好的話，傷疤會(huì)一直留在那里，這是 Linux Kernel 的開發(fā)者們所非常不愿意見到的事情。
?