On 08/10/15 03:00 PM, Daniel Stone wrote: > Hi, > > On 8 October 2015 at 08:27, Jonas Ådahl <jad...@gmail.com> wrote: >> On Mon, Oct 05, 2015 at 12:04:49PM -0500, Derek Foreman wrote: >>> There are cases in weston where it would be quite nice to have a >>> sentinel value to use instead of having to have a bool for "this serial >>> number is legit" too. >> >> Even though probably unlikely, for clients unaware of a possible 0 == no >> serial, this would mean that they would suddenly start to be killed when >> when they before worked just fine.
Arguably, those clients have always been buggy since they've already been passing bogus serial numbers the compositor never sent them in the first place... >>> >>>> In cases where we have two behaviors for serial-aware and >>>> non-serial-aware operations, I would rather have two different client >>>> requests. >> >> This would be my preference as well. Partly because the semantics of a >> request with a serial and one without will probably behave differently, >> and partly because the existing places where you pass a serial has >> mentioning of any "non-serial" or "invalid serial" situations and we'd >> now just add a bunch of undefined behaviour. I think this would be at worst "implementation defined" - not undefined. Can we agree that any client for which this is a concern already contains bugs? The behavior for using a serial that didn't come from an event is already undefined, isn't it? Perhaps it's a little harsh to kill processes for this, but logging an error in weston seems ok - would even help us catch buggy apps. >> Is it really a big deal to have to multiple requests that do things >> differently? I must confess to not actually understanding how present_from_serial with a "not-a-serial" parameter should do anything differently from "present" which isn't passed a serial. One is presenting with no serial and the other is... presenting with no serial. :/ Ultimately I suspect if two entry points were required, one would end up calling the other or they'd both call a common function that contained the bulk of the code. It seems we'd have a little less API and a little less spaghetti if we didn't do that. > Let's try to solve this empirically, then - which optional-serial > requests do we have apart from present/needs-attention here, and what > does/would the difference look like semantically? I can find no existing protocol in wayland/protocol or weston/protocol where a request would benefit from an optional serial number. Present/needs-attention seems to be the first I've come across. If we do add an invalid serial number (be it 0, 42, or 0xFFFFFFFF) then as far as I read, no existing request should ever be passed it and no existing event should ever come with it. (which is part of the reason I'm trying to convince myself it's not yet too late to add an invalid serial...) I'm not sure I can think of a case where an event should ever come with an invalid serial, but it seems like there could be other requests like present/present_with_serial. However, I don't really think that question was for me, as I'm pushing for this - I'm interested in hearing other answers... > Cheers, > Daniel > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
