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.
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.
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. |
| API | Overview |
|---|---|
| read,revc, etc | Reading basic file descriptors |
| mq_revc | API that can be received via a message queue file. |
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.
| 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.
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.
History of multiple I / O https://itkq.jp/blog/2017/05/10/linux-file-and-io/ Each link
Recommended Posts