Bug 69711 - mainloop wakeup is race-y and can eat 100% cpu
Summary: mainloop wakeup is race-y and can eat 100% cpu
Status: RESOLVED FIXED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-23 13:12 UTC by Pierre Ossman
Modified: 2014-06-06 12:37 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
0005-mainloop-avoid-race-y-double-wakeup-status.patch (1.72 KB, text/plain)
2013-09-23 13:12 UTC, Pierre Ossman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Ossman 2013-09-23 13:12:41 UTC
Created attachment 86366 [details]
0005-mainloop-avoid-race-y-double-wakeup-status.patch

There's been a lot of fiddling with the mainloop's wakeup code since I wrote it. Unfortunately the current implementation is race-y and can send pa_poll() into a loop where it returns right away and the process starts eating 100% CPU.

What happens is:

 1. pa_mainloop_wakeup() is called.

 2. A wakeup byte is written on the pipe.

 3. The atomic status variable is updated.

 4. clear_wakeup() is called.

 5. The atomic status variable is checked, and reset.

 6. The pipe is read, but data has yet to propagate from the write end to the read end so we get nothing.

 7. poll() is called, but returns quickly as there is now a byte sitting in the pipe.

 8. clear_wakeup() is called, but won't read anything since the atomic status claims the pipe is empty.

 9. goto 7.

The attached patch simply removes the extra variable. The pipe has atomic properties so it is quite sufficient by itself.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.