Hi,
I just merged those patches.
If you dislike the idea, please argue it well :)
If you dislike the name "slstr", please come up with nicer ideas, I'm all
open !
Btw I believe there is no need for any support in eo or eolian, as the
strings should be handled just like const char *.
Best regards,
On 13 January 2017 at 08:16, Carsten Haitzler <ras...@rasterman.com> wrote:
> 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
>
--
Jean-Philippe André
------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
