this is located in the bin/ecore_con directory, not bin/ecore_con/utils,
so ensure that we pass the correct path in order to avoid not finding the
file
@fix
ref T6713
Differential Revision: https://phab.enlightenment.org/D6515
Summary:
if the user or system attempts to cancel this thread then it should
stop blocking and exit in order to avoid potentially exiting after
efl has expected ecore-con to stop being active
@fix
fix T7041
Depends on D6354
Reviewers: ManMower, devilhorns
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7041
Differential Revision: https://phab.enlightenment.org/D6355
If the http proxy helper gets deleted at shutdown rather than because
the process actually exited, the object pointer becomes invalid. This
patch tries to avoid a situation where the object is not valid.
if proxy fails are too many then give up on queued lookups as they
likely will continue. i noticed a process continually spawning efl net
proxy helper because one queued lookup failed and could be looked up
so it kept trying again and again.
@fix
so here's the ugly problem. libproxy. yes. we've discussed memory
usage (e.g. it may have to execute javascript and pull in lots of deps
etc.) but we dlopene'd on the fly. ok... but this didn't solve another
issue i hit:
libproxy was causing enlightenment to abort(). some internal bit of
libproxy was raising a c++ exception. this wasn't caught. this causes
an abort(). takes down your entire desktop. FANTASTIC. this is bad. i
wouldnt' expect a library we depend on to be THIS anti-social but
libproxy seemingly is. it SHOULd catch its error sand just propagate
back to us so we can handle gracefully.
there reall is no way around this - isolate libproxy. it's even worse
that libproxy can load arbitrary modules that come from anywhere sho
who knows what issues this can cause. isolation is the best solution i
can think of.
so this makes an elf+net_proxy_helper we spawn the first time we need
a proxy lookup. we re-use that binary again and again until it exits
(it should exit after 10 seconds of being idle with no requests coming
in/pending). it'll respawn again later if needed. this involves now
the efl net threads having to marshall back to mainloop to do the
spawn and to write to the proxy process (reading is done by async exe
data events and the data is passed down a thread queue to the waitng
efl net thread). if the exe dies with pending requests unanswered then
it's respawned again and the req's are re-sent to it... just in case.
it has a limit on how often it'll respawn quickly.
this seems to work in my limited testing. this ALSO now isolates
memory usage of libproxy to another slave process AND this process
will die taking its memory with it once it's been idle for long
enough. that;s also another good solution to keeping libproxy impact
at bay.
Vincent Torri
Mike Blumenkrantz
Marcel Hollerbach
Jean-Philippe Andre
Carsten Haitzler
Gustavo Sverzut Barbieri