diff options
author | Alon Levy <alevy@redhat.com> | 2011-04-02 12:54:52 +0300 |
---|---|---|
committer | Alon Levy <alevy@redhat.com> | 2011-08-23 17:44:54 +0300 |
commit | 09ae4700d27b7c1cca64c2ce4c90f0c6cdf81ccf (patch) | |
tree | cca9910321cdfe30c4302ba6929e2f7cfa206fae /server/main_channel.h | |
parent | b6cf68604f2d184367d0f89834ebcce88e00bad8 (diff) | |
download | spice-09ae4700d27b7c1cca64c2ce4c90f0c6cdf81ccf.tar.gz spice-09ae4700d27b7c1cca64c2ce4c90f0c6cdf81ccf.tar.xz spice-09ae4700d27b7c1cca64c2ce4c90f0c6cdf81ccf.zip |
server: move pipe from RedChannel to RedChannelClient
Another cleanup patch, no change to behavior (still one client, and it
disconnects previous client if any).
The implementation for multiple client is straightforward: the pipe
remains per (channel,client) pair, so it needs to move from the RedChannel
that to RedChannelClient. Implementation using a single pipe with multiple
consumers (to reflect different latencies) doesn't fit well with pipe rewriting
that is used by the display channel. Additionally this approach is much simpler
to verify. Lastly it doesn't add considerable overhead (but see the display
channel changes in a later patch for a real place to rethink).
This patch is just technical, changing signatures to reflect the first
argument (oop style) so red_channel becomes red_channel_client. Some places
may seem odd but they should be fixed with later comits where the channels
grow to support multiple clients.
Sound (playback/record) channels are the only ones not touched - this is
consistent with previous patches, since they have been left out of the
RedChannel refactoring. That is left as future work. (note that they don't use
a pipe, which was the reason for not refactoring).
Diffstat (limited to 'server/main_channel.h')
0 files changed, 0 insertions, 0 deletions