| Age | Commit message (Collapse) | Author |
|---|
|
It's more ergonomic more often to behave consistently with
strlen() here, plus it's just the established mental model.
While here I made til_settings_path_as_buf() private as nothing
external uses it, it's essentially just a logically distinct
private helper function from the public wrappers around it.
Dragged into this changeset due to clarifying some
naming/semantics as it's one of the few til_str_to_buf() callers.
But nobody was actually passing a non-NULL res_bufsz/res_len to
it anyways, as its use is minimal.
|
|
Just more open_memstream() elimination
|
|
Preparatory commit for deprecating til_module_context_t.path in
favor of mandatory til_module_context_t.setup providing the
settings-derived context path.
Future commit will drop til_module_context_t.{path,path_hash}
|
|
This commit adds passing the settings instance to til_setup_new()
which is used for deriving a path for the setup via
til_settings_print_path() on the supplied settings.
That path gets an allocated copy left in the returned
til_setup_t at til_setup_t.path
This path will exist for the lifetime of the til_setup_t, to be
freed along with the rest of the baked setup instance when the
refcount reaches 0.
The incoming til_settings_t is only read @ til_setup_new() in
constructing the path, no reference is kept. Basically the
til_settings_t* is just passed in for convenience reasons, since
constructing the path needs memory and may fail, this approach
lets the existing til_setup_new() call error handling also
capture the path allocation failures as-is turning
til_setup_new() into a bit more of a convenience helper.
Note that now all code may assume a til_setup_t has a set and
valid til_setup_t.path, which should be useful for context
creates when a setup is available.
|
|
The whole point of til_setup_t is to represent the baked, most
conveniently usable form of a setup derived from one or more
settings instances. Things generally go from the serialization
format "settings string" to til_settings_t eventually culminating
in a til_setup_t.
So the process of making a til_setup_t is rather tedious and kind
of costly. Once into a til_setup_t it's desirable to just hang
on to this form and reuse it if possible. The way a til_setup_t
baked setup is put to use is in a read-only fashion where it
basically just informs behavior, so it makes a lot of sense to
enable refcounting the thing and letting whatever can make use of
it bump the refcount and hold onto the pointer, accessing the
contents whenever it needs to answer a question about that
particular setup.
The immediate impetus for this is actually rtv's snow_module
setup. In rtv every channel switch may recreate the context, if
the context has expired. In the case of the snow module, the
context always expires, and we definitely want to discard the
context while playing the next channel. But when the snow
resumes, in order to recreate the context as configured, we need
the same setup again. It just becomes clear that what's needed
is a way to pin the snow_module's setup for this reuse to be
safe.
There's also plenty of other modules that have been piecemeal
copying settings into their context, when what would really make
more sense is to just ref it and stow the pointer, then unref on
their context destroy. They can just access the setup via the
pointer as needed, instead of having to duplicate the setup in
their context. Indeed, some module contexts even embed the
entire setup just to copy its contents over by value. In
simple/small scenarios that's fine, and I'm sure in those
particular cases it's perfectly safe to do. It just seems
unnecessary altogether.
Another small change made is supporting NULL free_func, which
will default to libc's free(). Most til_setup_new() call sites
are passing free() with an annoying cast, those can be changed to
NULL.
|
|
simple wrapper around til_setup_t.free()
|
|
For use when setup functions allocate their private setup to
return in *res_setup.
They specify the size of their private setup, and supply the free
function to use. This may be libc's free() when it's a simple
setup struct, or a bespoke free function when deep/complex
freeing is required for cleanup.
It's expected that callers will be embedding til_setup_t at the
start of their private setup struct, and returning a pointer to
this in *res_setup which would be the same value as a pointer to
to their private setup struct.
|
