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.
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.
Perl now includes own `struct object` which clashes with elinks
implementation. Renamed `struct object` to `struct elinks_object` to
avoid it.
Bug: https://bugs.gentoo.org/909042
Implementation of ftpes and sftp is based on curl's hiperfifo example. It requires libevent.
ftpes only encrypts control channel. There were problems when both control and data were encrypted. It stucked on SIZE.
Only successful connections work, errors are not handled properly.
Note, configs and other files from ~/.elinks/ are not moved
to ~/.config/elinks/ automatically. You must do it yourself.
ELINKS_CONFDIR and HOME_ETC also are no longer supported.
