By default, builds will still not have XMLRPC enabled at all and the
configure flag `--with-xmlrpc-tinyxml2` must be specified. If both
xmlrpc-c and tinyxml2 are specified, xmlrpc-c takes precedence.
Basic benchmarks indicate tinyxml2 is 2x faster for small
requests/responses, and that only increases as response sizes get
larger.
This commit resolves a scgi software crash when the scgi socket is closed before the message can be sent. It instructs `::send()` not to send a SIGPIPE termination signal. Instead the value -1 is returned and handled bellow. The SCgiTask is closed and a new one is sent to complete the task.
```
Thread 3 "rtorrent scgi" received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fffe635c6c0 (LWP 2443872)]
0x00007ffff7929a84 in send () from /lib/x86_64-linux-gnu/libc.so.6
```
The erase/insert pattern can be replaced by a single method that
updates an existing entry's timer, or inserting if it doesn't exist.
This has much less impact than the libtorrent change it's based on,
but might as well be consistent.
This commit fixes a critical memory leak with the inserting RPC commands. We must initialize the cmd_flags with the delete key, otherwise they hang around in memory forever; potentially leaking significant amounts of resources.
From https://github.com/jesec/rtorrent/commit/f9a875b633eb083ec82f89ebeae8678ca424e8b2
This commit ensures session files land on the disk in the event of a system crash or power outage. It prevents data corruption of rTorrent session files, which causes torrent client breakage.
Optimizations from the initial implementation include
1) Skipping unnecessary file metadata updates during the sync process.
2) Skipping variable initialization since open will assign -1 on failure.
This commit fixes compiling rTorrent with LTO (Link Time Optimizations). We just need to rename from variables in the directory_entry structure to avoid ODR and ZLIB conflicts.
Author: kannibalox <kannibalox@gmail.com>
Date: Mon Jun 10 13:09:29 2024 -0400
Use regular iterators intead of bucket-local ones
Trying to manually predict which bucket a hashed key will land in does not
appear to be well-defined behavior.
Fixes#1285