I believe this function is not required and should not be
used by applications. If there is a very good use case to
use your own main freeq, then the API could be added again.
For now, removing the set() is probably the safer option.
Note: the API was introduced in the upcoming 1.19
Built on top of the new 'postponed' free queue, the short-lived
strings API allows users to return new strings without caring
about freeing them. EFL main loop will do this automatically for
them you at a later point in time (at the end of an iteration).
The APIs provided will either duplicate (copy) or more generally
steal an existing string (char *, stringshare, tmpstr, strbuf),
taking ownership of it and controling its lifetime. Those strings
can then be safely returned by an API. From a user point of view,
those strings must be considered like simple const char *, ie.
no need to free() them and their validity is limited to the
local scope.
There is no function to remove such a string from the freeq.
The short lived strings API is not thread-safe: do not send a
short-lived object from one thread to another.
@feature
While this reuses the existing (but new) infrastructure of
eina_freeq, the mode of operation and objective is very different
from the default freeq.
By default, any object added to the freeq is basically already
freed from the user point of view, and the freeq itself only adds
a tiny layer of memory safety by deferring the actual call to free
and optionally filling the memory blob with a pattern ('wwwww...').
This is mostly thread-safe (requires thread-safe free functions).
This new type I called postponed is intended to store objects that
will be short lived. This is not thread safe as the life of the
objects added to this queue depends on the thread that adds to
the queue. The main intent is to introduce a new API for short-lived
strings.
@feature
this allows environment variables to set the byte falue to fill a
freeq item added to the queue and then another item to actually fill
memory with just before the free function so memory content difference
will tell you if its inside the free queue or already freed from it
completely. if you set tyhe freed value to 0 this will not fill with a
value just before free and leave the value as-is determined by the
first fill pattern value.
this will make a freeq bypass that is enabled by using valgrind or env
var not affect a freeq that has manually changed its queue count max
or mem max. these now become explicit deferred freeers.
this adds eina_freeq api's for c land for deferring freeing of
pointers and can be used a s a simple copy & paste drop-in for free()
just to "do this later". the pointer will eveentually be freed as
eina_shutdown will free the main free queue and this will in turn free
everything in it. as long as the main lo0op keeps pumping things will
og on the queue and then be freed from it. free queues have limits so
if they get full they will clear out old pointers and free them so it
won't grow without bound. the default max is 1mb of data or 16384
items whichever limit is hit first and at that point the oldest item
will be freed to make room for the newest. the mainloop whenever it
finishes idle enterers will add an idler to spin and free while idle.
the sizes can be tuned and aruged about as to what defaults should be.
this also allows for better memory debugging too by being able to fill
freed memory with patterns if its small enough etc. etc.
@feature
Xavi Artigas
Bryce Harrington
Carsten Haitzler
Jean-Philippe Andre