http://www.win.tue.nl/~aeb/linux/lk/lk-12.html

12. Handling of asynchronous events

One wants to be notified of various events, like data that has become available, files that have changed, and signals that have been raised. FreeBSD has the nicekqueue API. Let us discuss the Unix/Linux situation.

It is easy to wait for a single event. Usually one does a (blocking) read(), and that is it.

Many mechanisms exist to wait for any of a set of events, or just to test whether anything interesting happened.

12.1 O_NONBLOCK

If the open() call that opened a file includes the O_NONBLOCK flag, the file is opened in non-blocking mode. Neither the open() nor any subsequent operations on the returned file descriptor will cause the calling process to wait.

A nonblocking open is useful (i) in order to obtain a file descriptor for subsequent use when no I/O is planned, e.g. for ioctl() calls to get or set properties of a device; especially on device files, an ordinary open might have unwanted side effects, such as a tape rewind etc. (ii) when reading from a pipe: the read will return immediately when no data is available; when writing to a pipe: the write will return immediately (without writing anything) when there are no readers.

O_NOACCESS

An obscure Linux feature is that one can open a file with the O_NOACCESS flag (defined as 3, where O_RDONLY is 0, O_WRONLY is 1 and O_RDWR is 2). In order to open a file with this mode, one needs both read and write permission. This had the same purpose: announce that no reading or writing was going to be done, and only a file descriptor for ioctl use was needed. (Used in LILO, fdformat, and a few similar utilities.)

People would love to have this facility also for directories, so that one could do a fd = open(".", O_NOACCESS), go elsewhere, and return by fchdir(fd). But an O_NOACCESS open fails on directories.

12.2 select

The select() mechanism was introduced in 4.2BSD. The prototype of this system call is

int select(int nfds, fd_set *restrict readfds,
fd_set *restrict writefds, fd_set *restrict errorfds,
struct timeval *restrict timeout);

It allows one to specify three sets of file descriptors (as bit masks) and a timeout. The call returns when the timeout expires or when one of the file descriptors inreadfds has data available for reading, one of those in writefds has buffer space available for writing, or an error occurred for one of those in errorfds. Upon return, the file descriptor sets and the timeout are rewritten to indicate which file descriptor has the stated condition, and how much time from the timeout is left. (Note that other Unix-type systems do not rewrite the timeout.)

There are two select system calls. The old one uses a parameter block, the new one uses five parameters. Otherwise they are equivalent.

12.3 pselect

The pselect system call was added in Linux 2.6.16 (and was present earlier elsewhere). With only select() it is difficult, almost impossible, to handle signals correctly. A signal handler itself cannot do very much: the main program is in some unknown state when the signal is delivered. The usual solution is to only raise a flag in the signal handler, and test that flag in the main program.

int gotsignal = 0;

void sighand(int x) {
gotsignal = 1;
} int main() {
...
signal(SIGINT, sighand);
while (1) {
if (gotsignal) ...
select();
...
}

Now if one wants to wait for either a signal or some event on a file descriptor, then testing the flag and if it is not set calling select() has a race: maybe the signal arrived just after the flag was tested and just before select was called, and the program may hang in select() without reacting to the signal.

The call pselect() is designed to solve this problem. This function is just like select() but has prototype

int pselect(int nfds, fd_set *restrict readfds,
fd_set *restrict writefds, fd_set *restrict errorfds,
const struct timespec *restrict timeout,
const sigset_t *restrict sigmask);

with a sixth parameter sigmask, and it does the equivalent of

sigset_t origmask;

    sigprocmask(SIG_SETMASK, &sigmask, &origmask);
ready = select(nfds, &readfds, &writefds, &exceptfds, timeout);
sigprocmask(SIG_SETMASK, &origmask, NULL);

as an atomic action. Now one can block the signals of interest until the call of pselect() and have a sigmask that unblocks them. If a signal occurs, the call will return with errno set to EINTR.

This function uses a struct timespec (with nanoseconds) instead of a struct timeval (with microseconds), and does not update its value on return.

The self-pipe trick

Before the introduction of pselect() people resorted to obscure tricks to obtain the same effect. Famous is Daniel Bernstein's self-pipe trick: create a non-blocking pipe, and add a file descriptor for reading from this pipe to the readfds argument of select(). In the signal handler, write a byte to the pipe. This works.

The system call

The pselect system call has a 7-parameter prototype (the 7th parameter being the size of the 6th sigmask parameter), but most architectures cannot handle 7-parameter system calls, so there is also a 6-parameter version where the 6th parameter is a pointer to a struct that has the last two parameters. Unlike the POSIX library routine, the system call does return the leftover part of the timeout.

This system call starts changing the signal mask, and ends restoring it. However, if it was interrupted by a signal, this signal should be delivered, while the signal mask might block it. This is solved by the recent TIF_RESTORE_SIGMASK mechanism in the kernel. When the pselect system call returns after being interrupted by a signal, it does not immediately restore the original signal mask, but first runs the user's signal handler, and first upon return from that the original signal mask is restored.

12.4 poll

The poll() system call is rather similar to select(). The prototype is

struct pollfd {
int fd; /* file descriptor */
short events; /* requested events */
short revents; /* returned events */
}; int poll(struct pollfd *fds, nfds_t nfds, int timeout);

where the fields events amd revents are bitmasks indicating for what events fd should be watched, and what conditions actually occurred. The timeout is in milliseconds; a negative number means an infinite timeout.

ppoll

Just like pselect is a version of select that allows safe handling of signals, ppoll is such a version of poll. The prototype is

int ppoll(struct pollfd *fds, nfds_t nfds,
const struct timespec *timeout, const sigset_t *sigmask);

12.5 epoll

When the number of file descriptors becomes very large, the select() and poll() mechanisms become inefficient. With N descriptors, O(N) information must be copied from user space to kernel and vice versa, and loops of length O(N) are needed to test the conditions.

Solaris introduced the /dev/poll mechanism (see poll(7d) on Solaris), where the idea is that one does the copy from user space to kernel only once (by writing an array of struct pollfd's to /dev/poll) and gets only interesting information back (via an ioctl on this device that copies the interesting struct pollfd back to userspace).

Linux tries something similar using the three system calls epoll_createepoll_ctlepoll_wait (added in 2.5.44, see epoll(7)). Benchmarks seem to indicate that the performance is comparable to that of select and poll until one has thousands of descriptors, only a small fraction of which is ready. (And then epoll is clearly better.) In most tests, the FreeBSD kqueue wins.

For a discussion of these and several other mechanisms, especially for the context of web servers, see the C10K site.

epoll_pwait

Just like pselect and ppoll are versions of select and poll, there is (since 2.6.19) a epoll_pwait version of epoll_wait that includes a signal mask.

12.6 dnotify

The above was about notification about file descriptors that become ready for I/O. A different type of notification is that about file system events. In 2.4.0-test9 the dnotify feature was introduced. Today it is obsoleted by inotify (see below). See Documentation/dnotify.txt and fs/dnotify.c.

The idea was that one could register interest in changes in a directory dir using fd = open(dir, O_RDONLY) followed by fcntl(fd, F_NOTIFY, ...). Notification occurs via delivery of a signal.

/* dnotify demo, basically from Documentation/dnotify.txt */
#define _GNU_SOURCE
#include <fcntl.h>
#include <signal.h>
#include <stdio.h>
#include <unistd.h> static volatile int dir_fd; /* A very weak interface: we report that something changed, but
the only info is in which directory, but not what the change is. */
static void handler(int sig, siginfo_t *si, void *data) {
dir_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 + 1, &act, NULL); fd = open(".", O_RDONLY);
fcntl(fd, F_SETSIG, SIGRTMIN + 1);
fcntl(fd, F_NOTIFY,
DN_MODIFY|DN_CREATE|DN_DELETE|DN_RENAME|DN_MULTISHOT); while (1) {
pause();
printf("Got some event on fd=%d\n", dir_fd);
}
}

There are many problems with this interface. It can only watch directories. If one wants to watch many directories, it takes many file descriptors. Moreover, the open file pins the filesystem so that it cannot be unmounted. When something happens it is unknown what, and a stat() on all files of interest is needed. The communication mechanism, signals, is unfortunate. Dnotify is obsolete now.

12.7 inotify

(Since 2.6.13.) Inotify is implemented using three new system calls and the usual read()poll()close() calls:

int inotify_init(void);
int inotify_add_watch (int fd, const char *pathname, int mask);
int inotify_rm_watch (int fd, int wd);

The first returns a file descriptor: fd = inotify_init(). The second tells what to watch, and what to watch for, and returns a watch descriptor: wd = inotify_add_watch(fd, "/home/aeb", IN_CREATE | IN_DELETE). The file descriptor fd can be used in a read() call, and then returns an array of struct inotify_event's. One can use select() and poll()on it. A watch is removed by inotify_rm_watch(fd,wd). The inotify instance is closed by close(fd).

An inotify_event is defined by

struct inotify_event {
int wd; /* Watch descriptor */
uint32_t mask; /* Mask of events */
uint32_t cookie; /* Unique cookie associating related
events (for rename(2)) */
uint32_t len; /* Size of 'name' field */
char name[]; /* Optional null-terminated name */
};

The name field defines the file involved, when one is watching a directory.

There is a /proc interface with settable limits:

% ls /proc/sys/fs/inotify/
max_queued_events max_user_instances max_user_watches
% cat $_/*
16384
128
8192

Applications are inotify-toolsgamin and Beagle.

/* inotify demo, mimicking the above dnotify one */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/select.h>
#include <sys/inotify.h> #define BUFSZ 16384 static void errexit(char *s) {
fprintf(stderr, "%s\n", s);
exit(1);
} int main(void) {
int ifd, wd, i, n;
char buf[BUFSZ]; ifd = inotify_init();
if (ifd < 0)
errexit("cannot obtain an inotify instance"); wd = inotify_add_watch(ifd, ".", IN_MODIFY|IN_CREATE|IN_DELETE);
if (wd < 0)
errexit("cannot add inotify watch"); while (1) {
n = read(ifd, buf, sizeof(buf));
if (n <= 0)
errexit("read problem"); i = 0;
while (i < n) {
struct inotify_event *ev; ev = (struct inotify_event *) &buf[i];
if (ev->len)
printf("file %s %s\n", ev->name,
(ev->mask & IN_CREATE) ? "created" :
(ev->mask & IN_DELETE) ? "deleted" :
"modified");
else
printf("unexpected event - wd=%d mask=%d\n",
ev->wd, ev->mask); i += sizeof(struct inotify_event) + ev->len;
}
printf("---\n");
}
}

Handling of asynchronous events---reference的更多相关文章

  1. (C#) Handling and Raising Events

    Handling and Raising Events .NET Framework 4.5   Other Versions     6 out of 20 rated this helpful - ...

  2. Java Concurrency In Practice - Chapter 1 Introduction

    1.1. A (Very) Brief History of Concurrency motivating factors for multiple programs to execute simul ...

  3. select&pselect/poll&ppoll/epoll

    select/pselect, poll和epoll的区别 select,epoll,poll比较 select,poll,epoll进化 Handling of asynchronous event ...

  4. Combine 框架,从0到1 —— 1.核心概念

      本文首发于 Ficow Shen's Blog,原文地址: Combine 框架,从0到1 -- 1.核心概念.     内容概览 前言 核心概念 RxSwift Combine 总结 参考内容 ...

  5. How does a single thread handle asynchronous code in JavaScript?

    原文:https://www.quora.com/How-does-a-single-thread-handle-asynchronous-code-in-JavaScript ----------- ...

  6. PatentTips - Use of multiple virtual machine monitors to handle privileged events

    BACKGROUND OF THE INVENTION A conventional virtual-machine monitor (VMM) typically runs on a compute ...

  7. Spring Events

    https://www.baeldung.com/spring-events by Eugen Paraschiv Spring+ I just announced the new Learn Spr ...

  8. asynchronous vs non-blocking

    http://stackoverflow.com/questions/2625493/asynchronous-vs-non-blocking In many circumstances they a ...

  9. Patterns for Asynchronous MVVM Applications: Commands

    Stephen Cleary Download the Code Sample This is the second article in a series on combining async an ...

随机推荐

  1. Discuz!和jQuery冲突的解决办法

    Common.js是官方自带的,我没改过它,所以不可能出错,所以问题就应该是两者冲突了.导致的结果我也发现了,前台的DIY功能不能用了.   我还花了很多时间在那里研究冲突的地方,后来还是没能解决.之 ...

  2. Replication--发布属性immediate_sync

    在创建发布时,如果选择立即初始化,会将immediate_sync属性设置为true.如果immediate_sync属性为true时,snapshot文件和发布事务及发布命令将一直保留到指定的事务保 ...

  3. django+echarts

    思路: 统一返回数据类型为json,然后前端发起Ajax请求后台数据接口 views.py def count_blog(request): # 下面等价于:select distinct auth, ...

  4. C#反射的基本应用

    反射描述了在运行过程中检查和处理程序元素的功能.反射可以完成以下任务: 枚举类型的成员: 实例化新对象: 执行对象的成员: 查找类型的信息: 查询程序集的信息: 检查应用于某种类型的自定义特性: 创建 ...

  5. solidity 合约间调用以及参数传递

    在 以太坊中合约间是可以相互调用,并且正常进行参数传递以及返回值处理. contract1.sol pragma solidity ^0.4.0; contract Test1 { uint256 p ...

  6. luoguP2479 [SDOI2010]捉迷藏

    https://www.luogu.org/problemnew/show/P2479 据说可以用线段树做但是我不会,只能写一个 KD-Tree 了 对于每个点求出距离它最远的点和最近的点的距离,然后 ...

  7. [USACO17DEC]Standing Out from the Herd(广义后缀自动机)

    题意 定义一个字符串的「独特值」为只属于该字符串的本质不同的非空子串的个数.如 "amy" 与 “tommy” 两个串,只属于 "amy" 的本质不同的子串为 ...

  8. 并发编程---线程 ;python中各种锁

    一,概念 在传统操作系统中,每个进程有一个地址空间,而且默认就有一个控制线程 线程顾名思义,就是一条流水线工作的过程,一条流水线必须属于一个车间,一个车间的工作过程是一个进程 --车间负责把资源整合到 ...

  9. Java - 多线程与锁

    进程-线程 进程,Process,处于运行中的程序,系统进行资源分配和调度的独立单位,拥有独立的内存空间(堆). 动态性:生命周期和状态: 独立性:独立实体: 并发性:Concurrency,抢占式多 ...

  10. CH5102 Mobile Service

    CH5102 Mobile Service 描述 一个公司有三个移动服务员,最初分别在位置1,2,3处.如果某个位置(用一个整数表示)有一个请求,那么公司必须指派某名员工赶到那个地方去.某一时刻只有一 ...