**Problem: Let's pretend rc has "set cmd:parallels 2;", so we are sure max_waiting=2 (otherwise max_waiting may never be updated as I explained in my previous mail). When invoking lftp with "lftp -c 'get http://file1;get http://file2;get http://file3;' , the files won't be downloaded in parallel (2 at a time). Get is an example, my point is commands are not executed in parallel when they are sent to lftp as arguments.
After the initial filefeeder (made when rc is read) dies, CmdExec::Do() returns too early. As it has no feeder, it returns in the following code, due to feeder==null: if(m != STALL || interactive || !feeder || waiting_num >= max_waiting) return m; There are more commands in the buffer (cmd_buf), and if the code didn't return there, they would be parsed and exec_parsed_command() would start them (until waiting_num>=max_waiting) **Tests: .lftp/rc: set cmd:parallel 2; set cmd:fail-exit false; lftp -c 'get http://file1;get http://file2;get http://file3;' It won't work in parallel. **Fix: Simply removing !feeder from the if seems to fix it. So you'd have: if(m != STALL || interactive || waiting_num >= max_waiting) return m; And anyway, after that code there is: if (cmd_buf.Size()==0 || partial_cmd) { if (feeder) { ...stuff... } return m; } If the buffer is empty and there is no feeder, the function returns m, as it was before the patch. However, if there are things in the buffer, they are executed. The only change is now commands can be spawned when the buffer is not empty, regardless of the existence of a feeder.
parallel_cli.patch
Description: Binary data
