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.

-- 
------------- 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

Reply via email to