<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Protocol: wl_buffer.release is racy"
href="https://bugs.freedesktop.org/show_bug.cgi?id=75303">75303</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>Protocol: wl_buffer.release is racy
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Reporter</th>
<td>ppaalanen@gmail.com
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Component</th>
<td>wayland
</td>
</tr>
<tr>
<th>Product</th>
<td>Wayland
</td>
</tr></table>
<p>
<div>
<pre>Consider a client doing this:
1. surface1.attach(buffer1)
2. surface1.commit
3. surface2.attach(buffer1)
4. surface2.commit
Then the client receives buffer1.release.
It is ambiguous, whether the release corresponds to step 2 or step 4. That is,
the client cannot know if the latter commit still holds the buffer reserved in
the server. The server may have had time to process and release the buffer
before step 4, in which case the buffer would be reserved again after step 4.
The problem is the same also, if surface1 and surface2 were both just surface1.
If the compositor has time to repaint in between the commits, the client may
get a release it most likely interprets as the release corresponding to step 4,
which would be wrong.
How should this be resolved?
A suggestion from Jason Ekstrand was to modify the protocol to guarantee one
release event for each commit that makes the buffer reserved. This would allow
clients to use simple reference counting.
Another possibility would be to require, that clients must not commit a
wl_buffer that is already reserved by the server. However, this seems quite
limiting, especially with the coming presentation extension that allows
queueing an arbitrary number of updates which could reference the same buffer
more than once (for e.g. simple cyclic animations like spinners or cursors).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>