curl: support parallel transfers

[bagder]

This is done by making sure each individual transfer is first added to a linked list as then they can be performed serially, or at will, in parallel.

Status

• creates a unique curl handle for each transfer and adds them to a linked list
• iterates over each transfer in the list and runs them one by one
• existing code and test cases adjusted
• minor behavior change documented
• ability to run transfers in parallel
• implement a basic progress meter for multiple concurrent transfers
• documented the new parallel option (-Z / --parallel)
• supports maximum N transfers done in parallel (--parallel-max)
• make sure --retry still works for serial transfers

Still TODO post first merge

• make --retry work for parallel
• make sure it handles torture tests fine
• test cases for parallel downloads
• work out how to report success/failures for individual transfers

[bagder]

The codacy warnings are just silly.

[MarcelRaad]

The codacy warnings are just silly.

You can turn that one off via Code patterns -> Flawfinder.

[bagder]

I can? I can't find anywhere to do that!

[MarcelRaad]

After "Login with GitHub", "Code patterns" appears at the menu on the left.

[jay]

I would just use --parallel and nix the short option, this seems like use will be almost always in scripts. I don't see anyone at the command line running curl -Z <fifty urls>.

confusing:
ckmopsuvwxz
CKMOPSUVWXZ

[jay]

I had one unreproducible hang while I was playing around with this, I'm not sure what caused it but during the investigation I found an off-by-one bug so I'm going to attribute it to that unless it happens again.

> curld --parallel -o first http://mirrors.rit.edu/ubuntu-releases/16.04/ubuntu-16.04.2-server-amd64.template
DL% UL%  Dled  Uled  Xfers  Live   Qd Total     Current  Left    Speed
--  --      0     0     1     1     0 --:--:-- --:--:-- --:--:-- -9223

That resource no longer exists, so I expect the tool to terminate almost immediately. The first time it didn't but every time after that it did (regardless of the fix).

[bagder]

thanks for the fixes @jay!

[jumoog]

I saw your YouTube video.. you can do a ETA if you request the file size of all urls first

[bagder]

No, I can't.

Primarily, lots of transfers libcurl can do simply do not know the size before-hand no matter what we do.
Secondly, for those that do, if we are to make 10,000 transfers it is not feasible to "get the size" of those 10K first before any transfers start. Partly because how libcurl works and partly because how those protocols work.

[bagder]

I've now moved a few of the remaining action items to get them done after the first merge, so that we can do the development of those things more parallel and with cooperation. As long as the non-parallel use cases still work exactly like before and are stable it shouldn't be a problem to proceed like this.

[jay]

My --write-outs are being overwritten by the progress meter. Simple example:

> curld --parallel --write-out "test %{http_code}" -o foo http://httpbin.org/get

DL% UL%  Dled  Uled  Xfers  Live   Qd Total     Current  Left    Speed
--  --    204     0     1     0     0 --:--:-- --:--:-- --:--:--  3290

In parallel_transfers after a transfer finishes post_transfer is called for that transfer, which does the write-out. However after that progress meter is called again which overwrites the line.

curl/src/tool_operate.c

Lines 2011 to 2040 in 80f044f

	if(!mcode) {
	int rc;
	CURLMsg *msg;
	bool removed = FALSE;
	do {
	msg = curl_multi_info_read(multi, &rc);
	if(msg) {
	bool retry;
	struct per_transfer *ended;
	CURL *easy = msg->easy_handle;
	result = msg->data.result;
	curl_easy_getinfo(easy, CURLINFO_PRIVATE, (void *)&ended);
	curl_multi_remove_handle(multi, easy);
	result = post_transfer(global, share, ended, result, &retry);
	if(retry)
	continue;
	progress_finalize(ended); /* before it goes away */
	all_added--; /* one fewer added */
	removed = TRUE;
	(void)del_transfer(ended);
	}
	} while(msg);
	if(removed)
	/* one or more transfers completed, add more! */
	(void)add_parallel_transfers(global, multi);
	}
	}
	(void)progress_meter(global, &start, TRUE);

"DL% UL%  Dled  Uled  Xfers  Live   Qd Total     Current  Left    Speed\n"
"test 200"  <---  result = post_transfer(global, share, ended, result, &retry); 
"\r--  --    204     0     1     0     0 --:--:-- --:--:-- --:--:--  3290\n"  <---  (void)progress_meter(global, &start, TRUE); 

[bagder]

Any suggestion on what to do with --write-out in a parallel scenario?

[jay]

Any suggestion on what to do with --write-out in a parallel scenario?

I'm not sure. Delay until finished?

[bagder]

I suppose it goes into the whole "how to show what happened for each transfer" discussion too. If you do 20 transfers, how are those --write-out going to make sense at the end...

[jay]

I suppose it goes into the whole "how to show what happened for each transfer" discussion too. If you do 20 transfers, how are those --write-out going to make sense at the end...

If they're done in the order they were given they could make some sense. Or there could be a transfer id like "%{transfer_id}"

[bagder]

I intend to merge this within shortly.

[MarcelRaad]

This broke the autobuilds. Unfortunately, it's not easy to see why in this huge diff:
https://curl.haxx.se/dev/log.cgi?id=20190722042000-16028#prob1

src/tool_operate.c:2290:11: error: implicit declaration of function 'easysrc_cleanup'; did you mean 'glob_cleanup'? [-Werror=implicit-function-declaration]

[jay]

This broke the autobuilds.

#4142