Hey,
On Jan 12, 2017 7:37 PM, "Carsten Haitzler" <ras...@rasterman.com> wrote:
On Thu, 12 Jan 2017 17:27:46 +0900 Jean-Philippe André <j...@videolan.org>
said:
> 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?
this is exxactly what i thought of when i allowed multiple freeq's to exist.
what you just need is an "unlimited size and count" freeq. so it stores
items
until explicitly cleared. well ok you need to create one as a tls and have
it
cleaned up on thread exit (the tls and what the freeq holds) you need a very
minimal wrapping of this (like get tls freeq. if null, create and set up
(with
tls free func) then add your string. if already there just add). your
"global"
clear func just accesses the tls and clears out the freeq. :)
that was one of the points behind freeq anyway... you just need unlimited
size/count mode. :)
Yes, yes, yes, and also yes. Well this is precisely the implementation I
did. :)
I'm quite simply adding an enum for the creation of the queue to specify
its type (so it cannot bypass).
Best regards,
Jp
------------------------------------------------------------------------------
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
