On Thu, 12 Jan 2017 15:29:07 +0200 Daniel Hirt <hirt.da...@gmail.com> said:

> Hi,
> 
> On Thu, Jan 12, 2017 at 10:27 AM, Jean-Philippe André <j...@videolan.org>
> wrote:
> 
> > Hello,
> >
> >
> > As mentioned in an earlier email I would like to introduce an auto-deleted
> > temporary strings API. For now it is called eina_slstr for short-live
> > strings[1]. The strings will be collected by the main loop after each
> > iteration, or whenever the thread exits, or on a manual call to the clear
> > function (eg. from a looping thread).
> >
> > Firstly, I can not reuse eina_tmpstr for this as it is used from multiple
> > threads. I tried. It made make check (eio_monitor) fail. So this requires a
> > whole new set of APIs.
> >
> >
> > // The goal is to be able to do something like:
> > ERR("This object %s is going crazy", object_string_get(obj));
> >
> > // With something like:
> > const char *object_string_get(Eo *obj)
> > {
> >   return eina_slstr_printf("%s@%p (%s)",
> >        efl_class_name_get(obj), obj, efl_name_get(obj));
> > }
> >
> > And not care about freeing the string. In an EO file we would just return a
> > "string" and the caller would need to then strdup() it to keep it alive.
> >
> > A del() function is optional (there is none in my patch).
> >
> >
> > A working implementation is in my devs/jpeg/work branch.
> >
> >
> > For this, I could reuse the Eina_FreeQ introduced by raster but add a new
> > behaviour. For now it's purely used for debugging as a "safe" call to free
> > (although it is arguable whether it will not in fact make debugging harder
> > in some cases).
> >
> > I'd like to introduce a POSTPONED mode where the freeq is not equivalent to
> > free() but rather queues up an item that will be collected at the next call
> > to the clear() function. Ecore main loop would clear automatically for the
> > main thread. Other threads would clear on exit automatically.
> >
> > This kind of queue would need to be thread local. Failure to clear the
> > queue from a looping thread would lead to massive memory leaks.
> >
> >
> > (optional) Another idea would be to have a MAIN_LOOP mode where the item to
> > be deleted will be pushed to a thread-safe queue flushed from the main
> > loop. (note: this is just an idea, my patches don't include this).
> >
> >
> > Alternatively eina_slstr can be implemented without a freeq, and keep the
> > freeq exclusively for a "safe" replacement to free().
> >
> >
> > Thoughts?
> >
> >
> I'd prefer to not piggyback on freeq. Won't a single loop iteration take A
> LOT longer
> to free the temporary string than what you would normally have if you'd just
> "strdup + use it + free" it? Just thinking of the amount of temporary
> memory piling
> up.
> Anyway the solution feels a bit artificial, unless I'm not getting the
> purpose of
> freeq.

no no. this i think is where you get confused. there is by default a single
global freeq run by the mainloop. *THIS* freeq is intended to "replace free"
by deferring frees until idle time later on (meaning pointers hopefully are
less aggressively recycled which means we get to .. hmmm hide bugs at runtime
or at least survive them more, but also we defer any free overhead/costs into
idle time but also if you enable memory pattern debug we can find memory issues
easily long before they hit us with "malloc internal crashes" with the mem
pattern debug stuff which i found already found me 1 error).

what jp is talking about is CREATING a separate freeq that specifically JUST
does these temp strings. in fact create one per thread (the first time it's
needed). the mainloop can run a "clean the queue" and this will clean it if it
exists... for the mainloop. but any thread can do the same as well when it is
done/idle or the tls cleanup func ca nuke the queue when the thread exits. it's
a special SEPARATE freeq just for these temporary strings.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


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

Reply via email to