Linux FD event API summary

This time I have an opportunity to use new event APIs such as libevent and libev, so I will summarize them. If you go deep into it, you can see this will happen, so just a brief introduction.

** Event flow here **

  1. Create a file descriptor.
  2. The standby side monitors the event with this file descriptor.
  3. The notifier notifies this file descriptor of the event.
  4. 2 detects the notified event and executes the process.

After that, if it is written as ** FD, please think of it as a file descriptor **.

It's an image of talking between threads, processes, etc. Depending on the item, the event monitoring and notification itself are wrapped so that the user is not aware of it. For example ...

--Since the OSS called libevent is a format for registering a function that is called when an event is detected, ** the user only needs to create a function that is called when an event is detected, and the event processing implementation is complete! ** ** --The API called timerfd is a library that issues timer events without permission, so if you create only the standby side, the timer processing implementation is complete! ** **

This kind of thing may be natural for high-level languages, but I think that the FD event, which has OSS ready and can be tuned up by yourself, is a function unique to C language.

** 1. File descriptor **

There are various. Since the event issuers of FD are substantial, is the event monitoring introduced later enriched, or vice versa? If you are interested, it may be interesting to look up history.

API Overview Remarks
open /dev/console(Standardoutput)Somethingwasopenandexchanged.Certainly. Donotperformoperationsondevicefilesthatshouldonlybeperformedonregularfiles
socket The API that you will learn first in communication processing. There are various options related to sending and receiving with setsockopt, so it is deep(Don't peep These options are used in various ways within OSS, so if you look at the OSS code, you will discover something unexpected.
socketpair Recommended when you want to use socket quickly. You can communicate with one API. While bidirectional communication is possible, it is difficult to use two FDs
eventfd AnAPIjustfornotifications.Countertype,sendnumberatsend(Ifitis0,FDdoesnotreact), The read side can read the counter. One FD is enough, so if it is one way, it may be better to devise this
timerfd A transcendental convenience API that issues an event after a certain period of time If you have an environment without timerfd, you should make your own. I like it at the level.
signalfd CreateanFDtopickupthesignal.Itisconvenienttobeabletopickupsignalsinthemainstandby. Signaldefinition,Notethatsignalhandlersareconstrained.Referenceofsignalfd
mq_open Open process for message queue files read/write is also done with a dedicated API.
pipe API to create FD that can be used for forked interprocess communication It is unidirectional communication instead of being available in fork.

** 2. Event monitoring **

** Receive function **

API Overview
read,revc, etc Reading basic file descriptors
mq_revc API that can be received via a message queue file.

** Event monitoring function **

If you simply receive it, it will be 1 API per 1FD, which is inefficient. Therefore, it is convenient to have a function to monitor FDs collectively. This function is substantial.

API Overview Personal impression
select, pselect Good old classic API,Also compatible with Windows It is better to use FD clearly. FD every time_It is troublesome to have to check with API such as ISSET
epoll Improved version of select, eliminating the trouble of constantly resetting the FD EPOLL_CTL_If you do ADD, FD will be added to the standby without permission, so it's easy. As a personal hobby, select is the best
libevent OSSthatwrapstheaboveeventmonitoringAPIandmakesitsimpletouse Thecallbackformatiseasytouse.However,ithasadelicateimpressionprobablybecauseitisnotthreadsafe.Abriefsummaryarticle
libev High-speedcompatibleversionabove.APIreference..DocumentisREADME⇒here。
Pleasereferto"WHATTOREADWHENINAHURRY"firstand"FUNCTIONSCONTROLLINGEVENTLOOPS"fordetails.
Documentsarealsosubstantial.IfthereisnoproblemwithGPL,itseemsgoodtoselectthis.
Evformultithreadeduse_default_loop(0)Not ev_loop_new, ev_loop, ev_Use unloop.

I think there are various samples above, but it is recommended to look at lighttpd's fdevent_XXX.c. It's all organized. Since the OSS code supports multiple environments, multiple processes are written, so you can see the guaranteed implementation of each function.

** 3. Event issuance **

API Overview
write,send Basic file descriptor writing
mq_send API that can be sent via a message queue file

Except for mq, write can be used for other FDs. In addition, timerfd is FD and event issuance.

** Other **

2018/06/19 postscript It's not FD, but there is also pthread_cond. Since it is used in combination with mutex, it may be good when it is already exclusive with mutex.

reference

History of multiple I / O https://itkq.jp/blog/2017/05/10/linux-file-and-io/ Each link

Recommended Posts

Linux FD event API summary
Linux Summary
[Linux] Basic command summary
OpenVPN Summary + Amazon Linux2
Linux a summary shortcut key
Summary of Linux distribution types
The Linux Watchdog driver API
[Linux] [Initial Settings] [Flutter] Summary
A brief summary of Linux
[Linux] User / group command summary
[Linux] [C / C ++] backtrace acquisition method summary
[Windows] Transfer event logs to Linux
Linux server construction link summary (CentOS7)