On Mon, 9 Jan 2017 10:29:08 -0200 Gustavo Sverzut Barbieri <[email protected]> said:
> 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! if i messed something up - please ping me... i did test and I *THINK* I got it right... make check is happy... my manual testing is happy... but i may have screwed something... > 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 :-/ ugh... so much... ugh. :( i know why you didn't do this. it's far more work than the dlopening of libproxy. but i got it wortking so i guess i did my 2c for the month :) > 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... i chose not to here as: 1. it'd be short-lived unless the app is continually doing network transactions that need proxy stuff (the 10sec timeout) 2. things like SMACK kind of screen the "1 process to share" ala efreetd. also efreetd doesn't work on windows atm - local ipcs doesn't work, so i chose this way as i thought it'd work... either way... the core exception not caught+abort issue is solved. and indeed if ti loads off of webkit it can do so in a slave we can kill. and i love killing slaves... MUHAHAHAHAHAHAHHA! :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
