On Mon, Jan 9, 2017 at 4:40 AM, Carsten Haitzler <[email protected]> wrote: > Just an FYI. > > Over the weekend I ran into a problem. A very unciable librpoxy was not > catching c++ exceptions, and these were being thrown becoming abort()'s taking > all of enlightenment down (stopping me from doing solid reliable testing of > e). > > It's really unsociable for any library to abort() or otherwise cause an abort. > It's one thing if you have a bug and you segfault, but if you just abort or > otherwise fail to catch exceptions you take everyone down with you. I had no > idea libproxy could be this much of an ass... > > So I had to do something about it. Luckily performance is much less of an > issue here, so I isolated libproxy use off to a helper binary that is executed > and talked to over stdout/in with a timeout if idle for 10sec or more. So > it'll > re-use it for a series of requests but then once it stops it'll release it. > > This also solves memory issues with pulling in things like js interpreters and > so on just to run pac files and the such. It's a far more complex design and > took me a while, but I've got it and make check seems to work for ecore_con. > well I get: > > 100%: Checks: 52, Failures: 0, Errors: 0 > > for it. It also has removed the enlightenment crashes, and it seems to work by > tracing messages back and forth from parent to child process using the ecore > con url download example. > > I've made this portable and not used fd's, fork or exec anywhere. Using > ecore_exe, eina_thread_queue and basic fgets/fprintf stdin/out in the slave > and > eina_thread + locks. > > It's not pretty, but it's kind of a necessary evil. We can't control libraries > we depend on. Eve if we patch them many users will for a long time not have a > patched version and if a work-around is possible, I guess that's a path to > choose if it doesn't really hurt. Here it adds a little latency to a lookup > after being idle, but it's a proxy lookup for a network request so it's going > to not be a huge impact given the cost of network traffic anyway. On the pus > side it solves the memory pollution as above so i deemed it a net positive to > do this even though the work was not fun. > > So just FYI.
Nice work! As I said when I introduce it, it would be nice to move that crap to its own process... it may even load the full webkitgtk depending on the plugin :-/ a minor improvement would be to share it with other processes by means of a daemon, or maybe reusing an existing one like efreetd... but that may come with its own drawbacks as well... -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
