Well, my Lord, I hate that idea. Do you want to make all EFL asynchronous? >From my point of view, seems to be like a hack cause some problems (e.g Eo) >are hard to solve.
My comments below. On Thu, 03 Nov 2016 16:11:24 +0900 Carsten Haitzler <ras...@rasterman.com> (The Rasterman) wrote: > here's an idea. it's very very very very simple > > create an eina_freeq(). instead of calling free() or whatever free > function on something immediately, call: > > fq = eina_freeq_main_get(); > eina_freeq_ptr_add(fq, pointer, size, free); > > or > > fq = eina_freeq_global_get(); > eina_freeq_ptr_add(fq, l, sizeof(Eina_List), > _eina_list_mempool_list_free); > > etc. > > and the free queue will "add this to the end" to be freed some time > later. the idea of size is so it could make intelligent choice like > to free very large chunks earlier than smaller allocations. the > mainloop would drive this actual freeing. or more specifically your > LOCAL loop would. need to add some kind of loop method that returns > the "free queue" FOR your loop/thread. or wherever you want it > actually freed. probably have a main free queue driven by the > mainloop (and cleared up on eina_shutdown) etc. > > why? > > 1. move overhead of doing actual frees out of critical code into idle > time > 2. improve stability by keeping memory eg for eo objects or eina > list nodes in a "free queue purgatory" for a while so if someone does > bad things like "use after free" the IMPACT is far smaller as they > mess with memory in the free queue not being used. Stability has to be improved with refs and other design technics, not with delay. More, we can't use anymore Valgrind. And this will be PITA to debug. The same kind of debug with async events where the frame before is ecore_loop... btw, the third point didn't leave your head ;-) > 4. be able to fill memory about to be freed with patterns (eg 0x55 or > 0xaa) so after free the memory is guaranteed to have a pattern to > know it was freed (optional debug only for mem regions of size > 0 > and maybe less than some max size). meow (I think this is what you say when you don't know if it is a good feature or not :-). > 5. optional - checksum the memory when added to free queue then check > checksum on actual free to warn of some code "being bad" and > scribbling over freed memory. at least we get warnings of lurking > bugs if we turn this on... Valgrind does it better. > > this doesn't solve everything, but it is an improvement and it's easy > to slide in and begin using very quickly - eg eo object data, eina > lists and a few other things. the free queue itself would be a very > very very low overhead buffer - not a linked list. maybe a mmaped or > malloced buffer/array (ring buffer) with a start and end point so we > dont do anything but write the above ptr, free ptr and maybe size to > the next array slot and move the ring buffer next slot one down. > > adding the freeq code in eina is a cakewalk. i'd spend more time > writing docs and tests than the code itself. :( adding usage of it > should be trivial. > > any comments? > ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
