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

[Tanu Kaskinen]

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+

> > 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.

> > (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.

-- 
Tanu

https://liberapay.com/tanuk
https://www.patreon.com/tanuk