mirror of
https://github.com/rkd77/elinks.git
synced 2024-06-27 01:25:34 +00:00
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). |
||
---|---|---|
.. | ||
bfu | ||
bookmarks | ||
cache | ||
config | ||
cookies | ||
dialogs | ||
document | ||
dom | ||
ecmascript | ||
encoding | ||
formhist | ||
globhist | ||
intl | ||
main | ||
mime | ||
network | ||
osdep | ||
protocol | ||
scripting | ||
session | ||
terminal | ||
util | ||
viewer | ||
.gitignore | ||
elinks.h | ||
Makefile | ||
meson.build | ||
README | ||
setup.h | ||
vernum.c | ||
vernum.h |
The Big View The whole dependency tree is supposed (in ideal world) to look somewhat like the following. Please note that this deals only with the core parts of ELinks, not extensions like bookmarks, cookies, globhist, mime etc. Those act like modules and are generally self-contained - the main visible difference is that they don't have their UI stuff in dialogs/foo.c but in foo/dialogs.c. Note also that it isn't all that clean-cut as it looks. Some parts of e.g. lowlevel/ or osdep/ are omnipresent as well and it's meant to be so (at least for now). Also some other exceptions are possible; the exception to this is util/, where no exceptions are permitted - it must have no dependencies to the rest of the code whatsoever, not even compile-time ones. The other way around, the gettext part of intl/ is generally omnipresent but the charset part is pretty isolated - it could be probably drawn as connected to document and terminal (actually, it is used when encoding forms in viewer too, but that stuff should be probably moved to document). viewer/ contains code concerning that big rectangle between bars at the top and bars at the bottom, documents usually being shown inside. Logically, it is in fact kind of a BFU widget, but in practice it has little in common with the bfu/ widgets, it is special in many ways and deeply woven to the fabric of session/ (e.g. session history is basically a chain of viewer widget descriptors). dialogs/ is special too. It in fact means to say "global and unique BFU instances belonging to the ELinks core"/ but that's a rather long and boring name, besides the nightmares associated with maintaining files and directories containing spaces in GIT. The "global and unique BFU instances" part can be represented by exmode, menus and leds (were they there). The "ELinks core" part can be represented by options, document and downloads. The reason those aren't in their respective directories (while bookmarks or formhist have their dialogs.c) is that it's important to keep the dependencies sorted out reasonably. Had there been e.g. terminal/dialogs.c, it would mean libterminal has to depend on libbfu.a and so. (There are two 'managerial' exceptions to this; don't dig into them, please. ;-) scripting/ (== browser scripting) is also expected to hook all around, perhaps it should be better in the omnipresent box. The edges are directed and represent the "using" relation. Therefore, "bfu -> terminal" means "bfu/ is using terminal/ services (but not the other way around)". .---------. | util/ | <-- This is omnipresent :) | config/ | | intl/ | `---------' .-------. .---------. | bfu |<------- | dialogs | `-------' \ `---------' v `---. | .----------. \ .--------. | terminal | <----- | viewer | <-----------------. / `----------' .> `--------' | .--' v / v v .-------. / .----------. | .----------. .----/ecmascript/----. | osdep |<------ | lowlevel | | | document | ----> | document scripting | `-------' \ `----------' | `----------' `--------------------' `---. ^ \ ^ \ .---------. `> .---------. .----/scripting/----. | network | <----- | session | -----> | browser scripting | `---------' / `---------' `-------------------' ^ .--' .----------. < | protocol | `----------'