Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
wayland
wayland
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 97
    • Issues 97
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 30
    • Merge Requests 30
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • wayland
  • waylandwayland
  • Issues
  • #46

Closed
Open
Created Feb 21, 2014 by Bugzilla Migration User@bugzilla-migration

Protocol: wl_buffer.release is racy

Submitted by Pekka Paalanen

Assigned to Wayland bug list

Link to original bug (#75303)

Description

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).

Blocking

  • Bug 83092
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None