diff options
author | Ryan Lortie <desrt@desrt.ca> | 2012-07-20 11:07:15 -0400 |
---|---|---|
committer | Ryan Lortie <desrt@desrt.ca> | 2012-07-20 11:07:15 -0400 |
commit | 1a580f4465d80bad209d7dccdad92063aa2861fa (patch) | |
tree | 20da193415f3cf0e5e5bb511398365d2b21a4e9f /gsettings/dconfsettingsbackend.c | |
parent | bc02d65a6c8defcee64022ba2f9a2607495281f7 (diff) | |
download | dconf-1a580f4465d80bad209d7dccdad92063aa2861fa.tar.gz |
GDBus thread backend: fix obscure race condition
It was possible for outgoing messages to be delivered in the wrong order
due to an annoying race condition when dealing with delivery of "fast"
change messages. This was hitting the in-order assertion on return of
those messages.
The race goes like this:
- a write is requested from the main thread (1 in-flight, 0 pending)
- the reply for this first change message comes back (but is not yet
handled).
- another write is requested from the main thread and immediately
placed in-flight (with an idle on the worker thread for actually
sending it). 2 in-flight, 0 pending.
- a third write is requested from the main thread but goes to the
pending queue (since the in-flight queue is full). 2 in-flight, 1
pending.
- the reply for the first change message is now handled in the worker
thread, removing the first change from the in-flight queue. The
queue management sees the third write in the pending queue and
promotes it to the in-flight queue (properly following the second
write) but sends the message immediately since it's already in the
worker thread (leapfrogging the second write which is still waiting
in an idle).
- the idle for the second write runs
We solve this problem by dispatching all writes via idles, even if we're
already in the worker thread.
Diffstat (limited to 'gsettings/dconfsettingsbackend.c')
0 files changed, 0 insertions, 0 deletions