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
