summaryrefslogtreecommitdiffstats
path: root/valgrind.supp
diff options
context:
space:
mode:
authorAnatol Pomozov <anatol.pomozov@gmail.com>2020-03-26 21:19:59 +0100
committerAllan McRae <allan@archlinux.org>2020-05-09 03:58:21 +0200
commita8a1a1bb3ec98a8471cb5cd13d096f39a267f789 (patch)
tree3a57e57e8dad88cc4bb51a0cd6b6d87d5a708b59 /valgrind.supp
parentfe8e13341bdeae4a59c0270a632c29e71ae9deda (diff)
downloadpacman-a8a1a1bb3ec98a8471cb5cd13d096f39a267f789.tar.gz
pacman-a8a1a1bb3ec98a8471cb5cd13d096f39a267f789.tar.xz
Introduce alpm_dbs_update() function for parallel db updates
This is an equivalent of alpm_db_update but for multiplexed (parallel) download. The difference is that this function accepts list of databases to update. And then ALPM internals download it in parallel if possible. Add a stub for _alpm_multi_download the function that will do parallel payloads downloads in the future. Introduce dload_payload->filepath field that contains url path to the file we download. It is like fileurl field but does not contain protocol/server part. The rationale for having this field is that with the curl multidownload the server retry logic is going to move to a curl callback. And the callback needs to be able to reconstruct the 'next' fileurl. One will be able to do it by getting the next server url from 'servers' list and then concat with filepath. Once the 'parallel download' refactoring is over 'fileurl' field will go away. Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
Diffstat (limited to 'valgrind.supp')
0 files changed, 0 insertions, 0 deletions