Hi,
On Thu, Jan 12, 2017 at 10:27 AM, Jean-Philippe André <[email protected]>
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.
>
>
> [1] tmpstr would have been better... synonyms to short-lived include
> temporary, ephemeral, transient, fleeting, volatile...
>
> --
> Jean-Philippe André
> ------------------------------------------------------------
> ------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
