<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#c9">Comment # 9</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:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>