[PATCH wayland] server: Make serial number 0 mean invalid
Derek Foreman
derekf at osg.samsung.com
Tue Oct 13 12:40:14 PDT 2015
On 08/10/15 03:00 PM, Daniel Stone wrote:
> Hi,
>
> On 8 October 2015 at 08:27, Jonas Ã…dahl <jadahl at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
More information about the wayland-devel
mailing list