mirror of
https://github.com/rkd77/elinks.git
synced 2025-01-03 14:57:44 -05:00
50841ff75f
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).
(cherry picked from commit
|
||
|---|---|---|
| config | ||
| contrib | ||
| cross | ||
| doc | ||
| docker | ||
| po | ||
| src | ||
| test | ||
| Unicode | ||
| .gitignore | ||
| .mailmap | ||
| ABOUT-NLS | ||
| AUTHORS | ||
| autogen.sh | ||
| BUGS | ||
| build.sh | ||
| ChangeLog | ||
| config2.h.in | ||
| configure.ac | ||
| COPYING | ||
| features.conf | ||
| git-dirty.sh | ||
| GOALS | ||
| INSTALL | ||
| Makefile | ||
| Makefile.config.in | ||
| Makefile.lib | ||
| meson_options.txt | ||
| meson.build | ||
| NEWS | ||
| README.md | ||
| SITES | ||
| test.sh | ||
| THANKS | ||
| TODO | ||
ELinks - an advanced web browser
ELinks is an advanced and well-established feature-rich text mode web
(HTTP/FTP/..) browser. ELinks can render both frames and tables, is highly
customizable and can be extended via scripts. It is very portable and runs
on a variety of platforms.
The ELinks official website is available at
http://elinks.cz/
Please see the SITES file for mirrors or other recommended sites. If you
want to install ELinks on your computer, see the INSTALL file for further
instructions.
A good starting point is documentation files available in doc/, especially the
file index.txt.
If you want to request features or report bugs, see community information at
http://elinks.cz/community.html and feedback information available at
http://elinks.cz/feedback.html.
If you want to write some patches, please first read the doc/hacking.txt
document.
If you want to add a new language or update the translation for an existing
one, please read po/README document.
If you want to write some documentation, well, you're welcome! ;)
Historical notes
~~~~~~~~~~~~~~~~
Initially, ELinks was a development version of Links (Lynx-like text WWW
browser), with more liberal features policy and development style. Its purpose
was to provide an alternative to Links, and to test and tune various new
features, but still provide good rock-solid releases inside stable branches.
Why not contribute to Links instead? Well, first I made a bunch of patches for
the original Links, but Mikulas wasn't around to integrate them, so I started
releasing my fork. When he came back, a significant number of them got refused
because Mikulas did not like them as he just wouldn't have any use for them
himself. He aims to keep Links at a relatively closed feature set and merge
only new features which he himself needs. It has the advantage that the tree is
very narrow and the code is small and contains very little bloat.
ELinks, on the contrary, aims to provide a full-featured web browser, superior
to both lynx and w3m and with the power (but not slowness and memory usage) of
Mozilla, Konqueror and similar browsers. However, to prevent drastic bloating
of the code, the development is driven in the course of modularization and
separation of add-on modules (like cookies, bookmarks, ssl, scripting etc).
For more details about ELinks history, please see
http://elinks.cz/history.html
If you are more interested in the history and various Links clones and versions,
you can examine the website at
http://links.sf.net/
Old ELinks team lost interest in ELinks development somehow. felinks (fork of
elinks) is continuation of elinks based on the master branch of the original
elinks repo with main releases (new features and other incompatible changes) no
more often than 1 yearly, and point releases (bugfixes) no more often than once
a month.
Repository was renamed to elinks on 2020-12-01 with Petr's approval.
Main repo is at
https://github.com/rkd77/elinks.git
vim: textwidth=80