# Multi Event Based A libcurl multi is operating "event based" when the application uses and event library like `libuv` to monitor the sockets and file descriptors libcurl uses to trigger transfer operations. How that works from the applications point of view is described in libcurl-multi(3). This documents is about the internal handling. ## Source Locations All code related to event based handling is found in `lib/multi_ev.c` and `lib/multi_ev.h`. The header defines a set of internal functions and `struct curl_multi_ev` that is embedded in each multi handle. There is `Curl_multi_ev_init()` and `Curl_multi_ev_cleanup()` to manage the overall life cycle, call on creation and destruction of the multi handle. ## Tracking Events First, the various functions in `lib/multi_ev.h` only ever really do something when the libcurl application has registered its callback in `multi->socket_cb`. This is important as this callback gets informed about *changes* to sockets. When a new socket is added, an existing is removed, or the `POLLIN/OUT` flags change, `multi->socket_cb` needs to be invoked. `multi_ev` has to track what it already reported to detect changes. Most applications are expected to go "event based" right from the start, but the libcurl API does not prohibit an application to start another way and then go for events later on, even in the middle of a transfer. ### Transfer Events Most event that happen are in connection with a transfer. A transfer opens a connection, which opens a socket, and waits for this socket to become writable (`POLLOUT`) when using TCP, for example. The multi then calls `Curl_multi_ev_assess_xfer(multi, data)` to let the multi event code detect what sockets the transfer is interested in. If indeed a `multi->socket_cb` is set, the *current* transfer pollset is retrieved via `Curl_multi_getsock()`. This current pollset is then compared to the *previous* pollset. If relevant changes are detected, `multi->socket_cb` gets informed about those. These can be: * a socket is in the current set, but not the previous one * a socket was also in the previous one, but IN/OUT flags changed * a socket in the previous one is no longer part of the current `multi_ev.c` keeps a `struct mev_sh_entry` for each sockets in a hash with the socket as key. It tracks in each entry which transfers are interested in this particular socket. How many transfer want to read and/or write and what the summarized `POLLIN/POLLOUT` action, that had been reported to `multi->socket_cb` was. This is necessary as a socket may be in use by several transfers at the same time (think HTTP/2 on the same connection). When a transfer is done and gets removed from the socket entry, it decrements the reader and/or writer count (depending on what it was last interested in). This *may* result in the entry's summarized action to change, or not. ### Connection Events There are also events not connected to any transfer that need to be tracked. The multi connection cache, concerned with clean shutdowns of connections, is interested in socket events during the shutdown. To allow use of the libcurl infrastructure, the connection cache operates using an *internal* easy handle that is not a transfer as such. The internal handle is used for all connection shutdown operations, being tied to a particular connection only for a short time. This means tracking the last pollset for an internal handle is useless. Instead, the connection cache uses `Curl_multi_ev_assess_conn()` to have multi event handling check the connection and track a "last pollset" for the connection alone. ## Event Processing When the libcurl application is informed by the event library that a particular socket has an event, it calls `curl_multi_socket_action()` to make libcurl react to it. This internally invokes `Curl_multi_ev_expire_xfers()` which expires all transfers that are interested in the given socket, so the multi handle runs them. In addition `Curl_multi_ev_expire_xfers()` returns a `bool` to let the multi know that connections are also interested in the socket, so the connection pool should be informed as well. ## All Things Pass When a transfer is done, e.g. removed from its multi handle, the multi calls `Curl_multi_ev_xfer_done()`. This cleans up the pollset tracking for the transfer. When a connection is done, and before it is destroyed, `Curl_multi_ev_conn_done()` is called. This cleans up the pollset tracking for this connection. When a socket is about to be closed, `Curl_multi_ev_socket_done()` is called to cleanup the socket entry and all information kept there. These calls do not have to happen in any particular order. A transfer's socket may be around while the transfer is ongoing. Or it might disappear in the middle of things. Also, a transfer might be interested in several sockets at the same time (resolving, eye balling, ftp are all examples of those). ### And Come Again While transfer and connection identifier are practically unique in a libcurl application, sockets are not. Operating systems are keen on reusing their resources, and the next socket may get the same identifier as one just having been closed with high likelihood. This means that multi event handling needs to be informed *before* a close, clean up all its tracking and be ready to see that same socket identifier again right after.