|
Udipe 1.0
Solving the riddle of high-throughput UDP
|
Logging configuration. More...
Go to the source code of this file.
Data Structures | |
| struct | udipe_log_config_s |
Typedefs | |
| typedef enum udipe_log_level_e | udipe_log_level_t |
| typedef void(* | udipe_log_callback_t) (void *, udipe_log_level_t, const char[], const char[]) |
| typedef struct udipe_log_config_s | udipe_log_config_t |
Enumerations | |
| enum | udipe_log_level_e { UDIPE_TRACE = 1 , UDIPE_DEBUG , UDIPE_INFO , UDIPE_WARN , UDIPE_ERROR , UDIPE_DEFAULT_LOG_LEVEL = 0 } |
Functions | |
| UDIPE_NODISCARD UDIPE_NON_NULL_RESULT UDIPE_PUBLIC const char * | udipe_log_level_name (udipe_log_level_t level) |
This header is the home of udipe_log_config_t, the subset of udipe_config_t that controls libudipe's logging behavior.
| typedef void(* udipe_log_callback_t) (void *, udipe_log_level_t, const char[], const char[]) |
Logging callback
This callback will only be called for logs above the udipe_log_config_t::min_level threshold. It takes the following arguments:
The logging callback will be called concurrently by udipe worker threads and must therefore be thread-safe.
| typedef struct udipe_log_config_s udipe_log_config_t |
Logging configuration
This data structure controls libudipe's logging behavior. Like other configuration data structures, it is designed such that zero-initializing it should result in sane defaults for many applications.
| typedef enum udipe_log_level_e udipe_log_level_t |
Log level/priority
libudipe uses the standard logging convention where logs have various priorities. In udipe_log_config_t, a certain minimal priority can be specified. Logs above this priority are recorded, and logs below this priority are not processed.
| enum udipe_log_level_e |
Log level/priority
libudipe uses the standard logging convention where logs have various priorities. In udipe_log_config_t, a certain minimal priority can be specified. Logs above this priority are recorded, and logs below this priority are not processed.
| Enumerator | |
|---|---|
| UDIPE_TRACE | Detailed debugging logs This is used for very verbose logs that are only useful when debugging complicated problems, and should only be enabled on very simplified error reproducers as they will spill out an unmanageable flow of information on unmodified production applications. Examples include decomposition of complex user requests into simpler operations, e.g. logs about every single packet that is successfully processed by a particular input/output data stream. \internal If you are unsure whether a particular event should be logged at `TRACE` level or not logged at all, ask yourself whether this log is needed to understand the control flow path that was taken within `libudipe`. A core goal of `TRACE` logs is to reduce the amount of debugging scenarios for which a dedicated debugger is needed. |
| UDIPE_DEBUG | Basic debugging logs This is used for rather verbose logs that are only useful when debugging `udipe`'s internal operation, best applied to simplified error reproducers (as they are very chatty on realistic use cases), and may have an unacceptable performance impact in production applications. Examples include lifecycle tracing of individual one-shot send/receive requests as they pass through the various components of `udipe`, or detailed info about each and every lost packet (note that the performance impact of such logging will make packet loss worse). |
| UDIPE_INFO | "For your information" logs This is used for application lifecycle events that are normal and infrequent in production applications. Examples include explaining the final `udipe` configuration after merging defaults and automatic system configuration detection with manual user configuration, or beginning to listen for incoming packets on some network port/address. |
| UDIPE_WARN | Warning logs This is used for events that are suspicious and may indicate a problem, but are fine in certain circumstances, and do not prevent the application to operate in a possibly degraded manner. Examples include detecting a system configuration that is suboptimal from a performance point of view, or low-frequency reporting of packet loss (once every N seconds where N is chosen to have no significant performance impact in production). Because the value of `errno` is unreliable, as you never know which function set or overwrote it, `errno`-related logs are also displayed at the `WARN` log level. |
| UDIPE_ERROR | Error logs This is used for logs that indicate a clear-cut problem from which the application may not manage to recover, and even if it does it will do so at the expense of failing to correctly honor a direct user request. Basically, anytime a function that should not fail fails, an error log is emitted to explain why exactly it failed. |
| UDIPE_DEFAULT_LOG_LEVEL | Default configuration placeholder for udipe_log_config_t::min_level If the `UDIPE_LOG` environment variable is set, then it determines this default. For example, setting `UDIPE_LOG=WARN` has the same effect as setting the log level to \ref UDIPE_WARN in the configuration struct. Otherwise the default is to emit logs of priority >= `INFO` in all builds, and additionally emit logs of priority `DEBUG` in `Debug` builds. \internal This log level must not be applied to actual logs from the libudipe implementation. It is only a user-facing configuration helper. |
| UDIPE_NODISCARD UDIPE_NON_NULL_RESULT UDIPE_PUBLIC const char * udipe_log_level_name | ( | udipe_log_level_t | level | ) |
Get the textual name of a certain log level
For example, when applied to UDIPE_ERROR, this function returns "ERROR".
As this function is meant to be used inside of logger implementations, it will exceptionally log invalid parameter errors to stderr as opposed to the user-specified logger.
1.9.8