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).
Not sure why a retry loop using MAX_BIND_TRIES / BIND_TRIES_DELAY
surrounds connect_to_af_unix(), since bind() is done elsewhere in the
code, and connect_to_af_unix() already has its own retry loop inside the
function, with its own set of defines for retries, i.e. MAX_CONNECT_TRIES
/ CONNECT_TRIES_DELAY, surrounding the connect(). No need to have two
levels of retry; if it's not successful within connect_to_af_unix() it
will never be.
If --test 1, then elinks is headless. Display is /dev/null.
console.exit(0); or console.exit(1);
terminates elinks session.
console.exit is implemented for spidermonkey only.
When ui.sessions.fork_on_start, we fork a process that has a different
fdout than get_output_handle() (which has hardcoded fdout of 1), so it
will never be considered term->master, yet this is the process we want
to wake up in SIGTSTP handler.
Since we cannot rely on term->master to determine if we are the master
process, we instead move master_pid to be set explicitly at the places
where we have information about whether our process is a master or a
slave: first on start, then once the interlink determination has been
made.
master_pid has to be set in both parent and child, because both will get
suspended and need to know which one needs to resume in background with
SIGCONT (the master). We can't inherit from the parent because it's
unknown at the time of fork.
Previously, master_pid worked correctly with fork_on_start=0,
-no-connect or -dump, but not with fork_on_start=1.
See #287 for background.
the tests do not allow ever matching the entries with DISPLAY=:0 test,
since it's hardcoded to force $DISPLAY unset
leave default unchanged, (forced unset), but just add a command line
flag if user wants to match the entry with $DISPLAY set in mailcap
