MemoryMonitor
GMemoryMonitor will monitor system memory and suggest to the application when to free memory so as to leave more room for other applications. It is implemented on Linux using the Low Memory Monitor (API documentation).
There is also an implementation for use inside Flatpak sandboxes.
Possible actions to take when the signal is received are:
Free caches
Save files that haven’t been looked at in a while to disk, ready to be reopened when needed
Run a garbage collection cycle
Try and compress fragmented allocations
Exit on idle if the process has no reason to stay around
Call man:malloc_trim(3) to return cached heap pages to the kernel (if supported by your libc)
Note that some actions may not always improve system performance, and so should be profiled for your application. malloc_trim(), for example, may make future heap allocations slower (due to releasing cached heap pages back to the kernel).
See type@Gio.MemoryMonitorWarningLevel for details on the various warning levels.
static void
warning_cb (GMemoryMonitor *m, GMemoryMonitorWarningLevel level)
{
g_debug ("Warning level: %d", level);
if (warning_level G_MEMORY_MONITOR_WARNING_LEVEL_LOW)
drop_caches ();
}
static GMemoryMonitor *
monitor_low_memory (void)
{
GMemoryMonitor *m;
m = g_memory_monitor_dup_default ();
g_signal_connect (G_OBJECT (m), "low-memory-warning",
G_CALLBACK (warning_cb), NULL);
return m;
}Don’t forget to disconnect the signal@Gio.MemoryMonitor::low-memory-warning signal, and unref the GMemoryMonitor itself when exiting.
Since
2.64
Inheritors
Types
The MemoryMonitorImpl type represents a native instance of the MemoryMonitor interface.
Functions
Given @connection to communicate with a proxy (eg, a #GSocketConnection that is connected to the proxy server), this does the necessary handshake to connect to @proxy_address, and if required, wraps the #GIOStream to handle proxy payload.
Asynchronous version of g_proxy_connect().
See g_proxy_connect().
Initializes the object implementing the interface.
Emitted when the system is running low on free memory. The signal handler should then take the appropriate action depending on the warning level. See the #GMemoryMonitorWarningLevel documentation for details.
Some proxy protocols expect to be passed a hostname, which they will resolve to an IP address themselves. Others, like SOCKS4, do not allow this. This function will return false if @proxy is implementing such a protocol. When false is returned, the caller should resolve the destination hostname first, and then pass a #GProxyAddress containing the stringified IP address to g_proxy_connect() or g_proxy_connect_async().