diff options
author | Yonit Halperin <yhalperi@redhat.com> | 2013-05-24 16:27:31 -0400 |
---|---|---|
committer | Yonit Halperin <yhalperi@redhat.com> | 2013-05-24 16:27:31 -0400 |
commit | b30daf38bfcb9e4a7c0e80b128493e0794469ba2 (patch) | |
tree | 8ce4cfb64fa3be4a4a6b9fb6757d1b2e17199648 /client | |
parent | 67471d046ba5ba6e17aeb9188de0085cca44423c (diff) | |
download | spice-b30daf38bfcb9e4a7c0e80b128493e0794469ba2.tar.gz spice-b30daf38bfcb9e4a7c0e80b128493e0794469ba2.tar.xz spice-b30daf38bfcb9e4a7c0e80b128493e0794469ba2.zip |
red_channel: replace an assert upon threads mismatch with a warning
The assert:
spice_assert(pthread_equal(pthread_self(), client->thread_id))
and the assert:
spice_assert(pthread_equal(pthread_self(), rcc->channel->thread_id))
were coded in order to protect data that is accessed from the main
context (red_client and most of the channels), from
access by threads of other channels (namely, the display and cursor
channels), and vice versa.
However, some of the calls to the sound channel interface,
and also the char_device interface, can be done from the vcpu thread.
It doesn't endanger these channels internal data, since qemu use global
mutex for the vcpu and io threads.
Thus, pthread_self() can be != channel->thread_id, if one of them is
the vcpu thread and the other is the io-thread, and we shouldn't assert.
Future plans: A more complete and complicated solution would be to manage our own thread for
spice-channels, and push input from qemu to this thread, instead of
counting on the global mutex of qemu
rhbz#823472
Diffstat (limited to 'client')
0 files changed, 0 insertions, 0 deletions