On 03/18/2014 01:40 PM, Tanu Kaskinen wrote: > On Tue, 2014-03-18 at 12:11 +0100, David Henningsson wrote: >> On 03/18/2014 09:23 AM, Tanu Kaskinen wrote: >>> module-zeroconf-publish assumes that if it creates two defer events, >>> then the one that was created first will be dispatched first. That's >>> a fair assumption in my opinion, so let's fix the ordering in >>> pa_mainloop. >> >> Are you sure there are no modules assuming the current behaviour, and >> thus will be broken with this patch? > > I don't know any good way to check that, so I'm not 100% sure. However, > I find it very unlikely that someone would expect events to be processed > in inverse order. > > That said, I don't think this is the right fix for the zeroconf-publish > crash. I was going to suggest that we'd document it in pa_mainloop_api > that defer events must be dispatched in creation order, but then I > realized we have no control over existing external mainloop > implementations, so we can't safely add that new promise to the API. > I'll fix the bug in a different way (by removing all defer event > ordering assumptions from zeroconf-publish). I agree this would be a better solution. Thanks for working on it. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
