文章是在网上搜到的，我只是截取了其中一段。
#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) {
// 收到信号后，就会执行信号处理例程。
// 而 pause() 也就结束了。
pause();
printf("Got event on fd=%d\n", event_fd);
}
}
上面这一小段例程，对于熟悉 Linux 系统编程的读者朋友们来说，是很容易理解的。程序首先注册一个信号处理例程，然后通知 Kernel，我要观察 fd 上的 DN_MODIFY 和 DN_CREATE 和 DN_MULTISHOT 事件。（关于这些事件的详细定义，请读者朋友们参阅文后所列的参考资料。） Linux Kernel 收到这个请求后，把相应的 fd 的 inode 给做上记号，然后 Linux Kernel 和用户应用程序就自顾自去处理各自的别的事情去了。等到 inode 上发生了相应的事件，Linux Kernel 就把信号发给用户进程，于是开始执行信号处理例程，用户程序对文件系统上的变化也就可以及时的做出反应了。而在这整个过程中，系统以及用户程序的正常运行基本上未受到性能上的影响。这里还需要说明的是，dnotify 并没有通过增加新的系统调用来完成它的功能，而是通过 fcntl 来完成任务的。增加一个系统调用，相对来说是一个很大的手术，而且如果设计不当，处理得不好的话，伤疤会一直留在那里，这是 Linux Kernel 的开发者们所非常不愿意见到的事情。