Is It Necessary to Deregister a Socket from Epoll Before Closing It

Is it necessary to deregister a socket from epoll before closing it?

From the man page:

Q6 Will closing a file descriptor cause it to be removed from all epoll sets
automatically?

A6 Yes, but be aware of the following point. A file descriptor is a
reference to an open file description (see open(2)). Whenever a
descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or
fork(2), a new file descriptor referring to the same open file description
is created. An open file description continues to exist until all file
descriptors referring to it have been closed. A file descriptor is
removed from an epoll set only after all the file descriptors referring to
the underlying open file description have been closed (or before if the
descriptor is explicitly removed using epoll_ctl(2) EPOLL_CTL_DEL). This
means that even after a file descriptor that is part of an epoll 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.

what's the best way to remove fd from epoll in my case?

Just close the socket fd. It will automatically deregister itself from epoll. I asked a similar question last year and got this answer:

Is it necessary to deregister a socket from epoll before closing it?

If you need to do additional cleanup on the write thread for this socket, just have your write thread also listen to the read-end of a pipe fd. Notify this thread by writing a single-byte to the pipe (but not before queuing up a message to a thread-safe message queue indicating the details of what to cleanup).

When epoll_wait returns indicating data on the pipe, read the bytes off the pipe, consume the messages on the queue, and do appropriate clean-up work.

Hope this helps.

Do I need to unregister fd from epoll/kqueue when closing socket?

In Tornado, you must call IOLoop.remove_handler before closing the socket. Epoll and kqueue will internally discover automatically that the socket has been closed, but the IOLoop itself still has some state (a mapping from file descriptors to handler functions) that needs to be cleaned up.

golang epoll must close socket after sending message?

There's a typo on the status line. Use

content = append(content, []byte("HTTP/1.1 200 OK\r\n")...)

The server should do one of the following to terminate the request body:

• Specify the Content-Length header with the length of the body.
• Write a chunked response with a terminating chunk.
• Specify Connection: close header and close connection after writing response.

Does Kqueue need close like epoll?

Yes.

Kqueue uses a file descriptor, exactly like epoll, meaning that it should be closed when you're done with it.

Mostly, the OS cleanup will close it if you didn't do so before the process terminated... however, this is considered a bad practice.

there is a flaw in epoll_data structure , is it necessary to improve it?

You can always use file descriptor stored in epoll_data instance to index/key into your own data array/hash. Or you can always use the pointer member of that union and have all your metadata in your custom data structure. In other words, you already can make it consistent.

In my opinion, the minimal OS interface is preferable.

epoll recv return value

It means that you have already read all the data that has been sent overthe connection, and the only thing left is a TCP FIN, which could be the result of either a full close by the remote or a shutdown for output by the remote. You can't do much but close the socket at this point, unless you know the peer has only shutdown, in which case you can still write to the socket. Your application protocol determines all that.

There is no such thing as a request or response in TCP. There is just a bidirectional byte-stream.

---

Related Topics