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.
