<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Protocol: wl_buffer.release is racy" href="https://bugs.freedesktop.org/show_bug.cgi?id=75303#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Protocol: wl_buffer.release is racy" href="https://bugs.freedesktop.org/show_bug.cgi?id=75303">bug 75303</a> from <a class="email" href="mailto:jadahl@gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>(In reply to Pekka Paalanen from <a href="show_bug.cgi?id=75303#c9">comment #9</a>) > (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=75303#c8">comment #8</a>) > > Ok, yes I see it now.(In reply to Pekka Paalanen from <a href="show_bug.cgi?id=75303#c7">comment #7</a>) > > (In reply to Pekka Paalanen from <a href="show_bug.cgi?id=75303#c5">comment #5</a>) > > > Client side reference counting, that is, for every committed attach there > > > will be a release, seems like the preferred solution to me at the moment. > > > > How do you expect the client to get the new semantics (one release per > > commit) or do you mean to change it for everyone? > > For everyone, yes. > > I would hope that attaching the same wl_buffer to multiple surfaces is rare > enough that we can get away with it. Committing the same wl_buffer to a > surface before waiting for a release or a frame callback is I hope equally > rare. (If you wait for frame callback, you're probably going to draw, so > using a busy buffer is a mistake to begin with. If you wait for a release, > there is no race.) > > Since you cannot get the wl_buffer out of EGL, EGL should never hit a case > where the client-side reference count would be more than one. > > Also judging by krh's comment, it was probably expected to work in refcount > manner to begin with, we (probably just me) just screwed up the spec and > Weston. > > Bumping the wl_surface version for this is IMO a backup plan, in case we > can't just change the semantics for everyone. > > For now, this is a quite theoretical race, which is why I think we can solve > this now. With Presentation queueing that would change, so this must be > solved before queueing can get further. Reading between the lines in the description, one could assume only one surface was considered, since it only talks about that scenario, so I agree it should be a reasonable change to do. The only issue would be that it's hard for the client (especially EGL) to know when it can rely on the multi-surface case to work properly, especially if it's not possible to get the version of the bound (wl_surface) proxy (or the newest version supported by the server). I experimented once with implementing a "wl_version" interface to solve a similar issue (request version information from the server given an existing object) without needing to change any client API, but feels a bit hacky to need to do such a roundtrip.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>