[pulseaudio-discuss] [patches] constification round #4 (pa_mainloop_api)

[jnqnfe at gmail.com]

On Tue, 2018-07-10 at 13:54 +0300, Tanu Kaskinen wrote:
> On Mon, 2018-07-09 at 18:16 +0100, jnqnfe at gmail.com wrote:
> > On Mon, 2018-07-09 at 13:23 +0300, Tanu Kaskinen wrote:
> > > On Thu, 2018-07-05 at 23:51 +0100, jnqnfe at gmail.com wrote:
> > > > On Wed, 2018-07-04 at 11:46 +0300, Tanu Kaskinen wrote:
> > > > > Patch 4 changes the callback signatures.
> > > > 
> > > > Right, but only in the mainloop api vtable, which user's only
> > > > read
> > > > values from, so I wasn't expecting that to be an issue.
> > > 
> > > Applications can also write to it, if they implement their own
> > > mainloops.
> > 
> > Ah, that use case was not mentioned in our previous discussion. I'd
> > asked if the api struct was immutable, or whether there was any
> > intention to allow users to modify it, to say hijack one or more
> > function implementations (i.e. a partial customised mainloop), and
> > you'd said that there was no such intention. That discussion left
> > me
> > with the understanding that custom/partial-custom mainloops weren't
> > a
> > thing.
> > 
> > Do you happen to know of any examples of such programs implementing
> > custom mainloops that create and pass around a mainloop-api vtable
> > populated with their own pointers?
> 
> Debian Code Search gives a few examples:
> 
> https://codesearch.debian.net/search?q=defer_new+%3D+

Ok, thanks I'll take a look at those

> > > When I wrote my previous mail, I thought that patch 4 also
> > > changes
> > > the event callback types (pa_io_event_cb_t etc.), and that was
> > > what I
> > > was primarily concerned about
> > 
> > Yeah I deliberately left change to those callback signatures until
> > a
> > later commit (#25 of 26 I believe), for precisely those same
> > concerns.
> 
> I don't know if you realized, but already patch 2 depends on that
> change.

Yes, but patches 2 & 3 only depend on it to avoid a warning, which I
hoped was acceptable until the later few API change patches would make
it into a new major version

> > > (but applications implementing their own mainloops is still a
> > > real
> > > problem).
> > 
> > Right... :/
> > Well, I guess no matter how rare custom mainloops might be, if
> > custom
> > mainloops are a legit supported feature, then this change breaks it
> > and
> > thus must be considered API breakage, and that holds back
> > effectively
> > the entire patch set until you're willing to issue a new API-break
> > release :/
> 
> If we're ever going to make "libpulse 2", we need to have a plan
> about
> everything that we want to change. I don't want to create a new
> library
> just to constify the mainloop API... Feel free to start a wiki page
> that lists compatibility breaking changes that we might want to make.

Oh. I'm not used to library maintenance. I wasn't expecting a new lib
to be necessary for some ABI-compatible API changes, just a new major
version with an API bump to the API declaration in the version
header...

On the topic of such a list though, all that I would have in mind
besides the mainloop-api thing would be the purging of autoload (plus
removal of a related attribute in the middle of a struct that my
previous 'purge-autoload' patch deliberately left untouched), and a
switch to use of boolean parameters.