mirror of https://github.com/mkerrisk/man-pages
epoll.7: Reformat Q&A list
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
4f4b395de2
commit
6832efaf3c
60
man7/epoll.7
60
man7/epoll.7
|
@ -326,24 +326,20 @@ calling
|
|||
with
|
||||
.BR EPOLL_CTL_MOD .
|
||||
.SS Questions and answers
|
||||
.TP 4
|
||||
.B Q0
|
||||
.IP 0. 4
|
||||
What is the key used to distinguish the file descriptors registered in an
|
||||
.B epoll
|
||||
set?
|
||||
.TP
|
||||
.B A0
|
||||
.IP
|
||||
The key is the combination of the file descriptor number and
|
||||
the open file description
|
||||
(also known as an "open file handle",
|
||||
the kernel's internal representation of an open file).
|
||||
.TP
|
||||
.B Q1
|
||||
.IP 1.
|
||||
What happens if you register the same file descriptor on an
|
||||
.B epoll
|
||||
instance twice?
|
||||
.TP
|
||||
.B A1
|
||||
.IP
|
||||
You will probably get
|
||||
.BR EEXIST .
|
||||
However, it is possible to add a duplicate
|
||||
|
@ -373,37 +369,31 @@ This can be a useful technique for filtering events,
|
|||
if the duplicate file descriptors are registered with different
|
||||
.I events
|
||||
masks.
|
||||
.TP
|
||||
.B Q2
|
||||
.IP 2.
|
||||
Can two
|
||||
.B epoll
|
||||
instances wait for the same file descriptor?
|
||||
If so, are events reported to both
|
||||
.B epoll
|
||||
file descriptors?
|
||||
.TP
|
||||
.B A2
|
||||
.IP
|
||||
Yes, and events would be reported to both.
|
||||
However, careful programming may be needed to do this correctly.
|
||||
.TP
|
||||
.B Q3
|
||||
.IP 3.
|
||||
Is the
|
||||
.B epoll
|
||||
file descriptor itself poll/epoll/selectable?
|
||||
.TP
|
||||
.B A3
|
||||
.IP
|
||||
Yes.
|
||||
If an
|
||||
.B epoll
|
||||
file descriptor has events waiting, then it will
|
||||
indicate as being readable.
|
||||
.TP
|
||||
.B Q4
|
||||
.IP 4.
|
||||
What happens if one attempts to put an
|
||||
.B epoll
|
||||
file descriptor into its own file descriptor set?
|
||||
.TP
|
||||
.B A4
|
||||
.IP
|
||||
The
|
||||
.BR epoll_ctl (2)
|
||||
call fails
|
||||
|
@ -413,24 +403,20 @@ However, you can add an
|
|||
file descriptor inside another
|
||||
.B epoll
|
||||
file descriptor set.
|
||||
.TP
|
||||
.B Q5
|
||||
.IP 5.
|
||||
Can I send an
|
||||
.B epoll
|
||||
file descriptor over a UNIX domain socket to another process?
|
||||
.TP
|
||||
.B A5
|
||||
.IP
|
||||
Yes, but it does not make sense to do this, since the receiving process
|
||||
would not have copies of the file descriptors in the
|
||||
.B epoll
|
||||
set.
|
||||
.TP
|
||||
.B Q6
|
||||
.IP 6.
|
||||
Will closing a file descriptor cause it to be removed from all
|
||||
.B epoll
|
||||
sets automatically?
|
||||
.TP
|
||||
.B A6
|
||||
.IP
|
||||
Yes, but be aware of the following point.
|
||||
A file descriptor is a reference to an open file description (see
|
||||
.BR open (2)).
|
||||
|
@ -457,34 +443,28 @@ This means that even after a file descriptor that is part of an
|
|||
set has been closed,
|
||||
events may be reported for that file descriptor if other file
|
||||
descriptors referring to the same underlying file description remain open.
|
||||
.TP
|
||||
.B Q7
|
||||
.IP 7.
|
||||
If more than one event occurs between
|
||||
.BR epoll_wait (2)
|
||||
calls, are they combined or reported separately?
|
||||
.TP
|
||||
.B A7
|
||||
.IP
|
||||
They will be combined.
|
||||
.TP
|
||||
.B Q8
|
||||
.IP 8.
|
||||
Does an operation on a file descriptor affect the
|
||||
already collected but not yet reported events?
|
||||
.TP
|
||||
.B A8
|
||||
.IP
|
||||
You can do two operations on an existing file descriptor.
|
||||
Remove would be meaningless for
|
||||
this case.
|
||||
Modify will reread available I/O.
|
||||
.TP
|
||||
.B Q9
|
||||
.IP 9.
|
||||
Do I need to continuously read/write a file descriptor
|
||||
until
|
||||
.B EAGAIN
|
||||
when using the
|
||||
.B EPOLLET
|
||||
flag (edge-triggered behavior) ?
|
||||
.TP
|
||||
.B A9
|
||||
.IP
|
||||
Receiving an event from
|
||||
.BR epoll_wait (2)
|
||||
should suggest to you that such
|
||||
|
|
Loading…
Reference in New Issue