1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
/*
* Copyright (c) 2009-2012 Niels Provos and Nick Mathewson
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/*
A "changelist" is a list of all the fd status changes that should be made
between calls to the backend's dispatch function. There are a few reasons
that a backend would want to queue changes like this rather than processing
them immediately.
1) Sometimes applications will add and delete the same event more than
once between calls to dispatch. Processing these changes immediately
is needless, and potentially expensive (especially if we're on a system
that makes one syscall per changed event).
2) Sometimes we can coalesce multiple changes on the same fd into a single
syscall if we know about them in advance. For example, epoll can do an
add and a delete at the same time, but only if we have found out about
both of them before we tell epoll.
3) Sometimes adding an event that we immediately delete can cause
unintended consequences: in kqueue, this makes pending events get
reported spuriously.
*/
/** Represents a */
;
/* Flags for read_change and write_change. */
/* If set, add the event. */
/* If set, delete the event. Exclusive with EV_CHANGE_ADD */
/* If set, this event refers a signal, not an fd. */
/* Set for persistent events. Currently not used. */
/* Set for adding edge-triggered events. */
/* The value of fdinfo_size that a backend should use if it is letting
* changelist handle its add and delete functions. */
/** Set up the data fields in a changelist. */
void ;
/** Remove every change in the changelist, and make corresponding changes
* in the event maps in the base. This function is generally used right
* after making all the changes in the changelist. */
void ;
/** Free all memory held in a changelist. */
void ;
/** Implementation of eventop_add that queues the event in a changelist. */
int ;
/** Implementation of eventop_del that queues the event in a changelist. */
int ;