[pulseaudio-discuss] [patches] constification round #4 (pa_mainloop_api)
Tanu Kaskinen
tanuk at iki.fi
Fri Jun 29 13:06:37 UTC 2018
On Thu, 2018-06-28 at 04:08 +0100, jnqnfe at gmail.com wrote:
> constification round #4 (pa_mainloop_api)
>
> 26 patches in total. I attached a zipped copy also.
>
> The first 19 avoid (client) API change; the final 7 do not and will
> have to wait until ready and happy to do an API bump.
>
> I'm not certain if there's a public API for 3rd-party modules, but if
> so then I can anticipate issue being taken with respect to
> pa_iochannel_get_mainloop_api() in #14. Unpicking that though would not
> be so easy :/
There's no public API for modules.
> It's possible for patches #21, #23 and #24 to be bumped down before the
> API change of #20, but as things are they are blocked by it and it
> would require a temporary hack... #23 and #24 (utils) depend upon
> pa_signal_init(), done in #21 which involves changing the underlying
> static; this depends upon changing pa_signal_destroy_cb_t (#20),
> because of the way pa_signal_free() works (passing that static api ref
> to the destroy callback which requires non-const). Getting around this
> would require injecting a temporary hack into pa_signal_free() giving
> alternate means of obtaining a non-const api pointer - i.e. api
> function pointer comparison would be necessary to tell us which
> mainloop is in use, to then get what we need using the correct
> *_get_api() with api->userdata.
We can't change the signatures of publicly declared callback types.
That will cause incompatibilities (compiler warnings at least, which is
bad enough) in applications. Therefore the only patch that I could
apply is the first one.
--
Tanu
https://liberapay.com/tanuk
https://www.patreon.com/tanuk
More information about the pulseaudio-discuss
mailing list