protocol.ftp.curl_max_recv_speed
protocol.ftp.curl_max_send_speed
protocol.http.curl_max_recv_speed
protocol.http.curl_max_send_speed
Unit is byte per second. 0 - unlimited.
When the first elinks session starts (whether fork_on_start or not), it
tries to connect on AF_UNIX socket, to see if an existing master is
present. The current code implements a retry loop with linear-increase
retry backoff, 50ms *= attempts, with 3 attempts, total delay 300ms,
before concluding master is not present.
After forking for fork_on_start, we do have to wait for the new master
to finish setup, so we can connect to it. This is the case where retry
loop might be useful. However in fork_on_start=0 case, there should be
no reason to ever wait: if we get ECONNREFUSED or ENOENT, the master
simply is not there, we can go on about our business as the master.
With fork_on_start=1 however, we will race with the child (that will
become the new master), which has to complete its socket/bind/listen
sequence. Therefore we typically have to wait another 50ms (first
attempt delay), for a total of 350ms delay.
In both cases, there does not seem to be a purpose to the initial
connection attempt retry. Conclusion after connect() failure should be
authoritative: there is no master. We do not race with anyone.
If we have done fork_on_start and have to wait, we can instead open a
pipe before forking, and wait for the "new" master (its child) to send
us a byte over the pipe. Thus, we do not need to poll, but can simply
block until we get the trigger, to indicate that AF_UNIX socket setup
has completed.
This speeds up the first start of elinks by 300ms for fork_on_start=0,
and between 300-350ms for fork_on_start=1 (or possibly more, if the
machine is loaded and child did not finish AF_UNIX setup in first 50ms).
