[Spice-commits] Changes to 'server_multi_client.v5.wip'
Alon Levy
alon at kemper.freedesktop.org
Thu May 5 06:38:39 PDT 2011
New branch 'server_multi_client.v5.wip' available with the following commits:
commit e43ec5e63fc52f1a4abf3ddbe68687d5a2934971
Author: Alon Levy <alevy at redhat.com>
Date: Wed Nov 17 22:56:27 2010 +0200
(temp) client/red_channel: DEBUG: allow no SSL usage (useful for valgrind)
commit 9104722b3b64d4c7f0a1002f9b967e2acf1e8ef0
Author: Alon Levy <alevy at redhat.com>
Date: Wed Nov 17 23:07:31 2010 +0200
(temp) server/reds: DEBUG: add a define for working with no SSL (good for valgrind)
commit 5ab759cc29d4324e88c342ca671a6e81f2e5e77f
Author: Alon Levy <alevy at redhat.com>
Date: Wed Nov 24 12:47:39 2010 +0200
(temp) server/reds: use ALLOW_NO_SSL define externally to trigger debug only DEBUG_GENERATE_NULL_KEY
commit 3fe9eff11cdc91b2d736f8f4a6946dd5e07239b8
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 13:42:03 2011 +0300
server/red_worker: DEBUG_CURSORS
Add cursor allocation debugging code that is turned off as long as
DEBUG_CURSORS is not defined.
commit 8df1ced7d2f823c12f35dac13360f490bbbfcb08
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 12:03:28 2011 +0300
server/red_worker: give each client a different id for caches
We need to have a different id for each client, otherwise we get a reference to
other client's cache, and of course we don't sync with the new client.
NOTE: This is quite strange - why are we using a client provided id? only makes sense
for migration (it already has cache, we get cache by migration). So right now
we will advance the id if we find it is already there, unless migrate is on, in
which case we do nothing.
At this point connecting multiple clients with display and cursor channels works.
previously you could already connect with multiple clients where the second and
more used only the inputs channel.
You can still crash on lack of Drawables or CursorItems due to speed mismatch between
the clients (easier to trigger with windows vms).
This will be fixed in later patches by introducing pipe squashing.
FIXME: Note that the current patchset turns on multiclient support unconditionaly. This must
be fixed before applying, by adding spice api and using it from qemu (and relevant testers
will help too).
commit e53783802322c2ac3bf46387312bf1c9f7504ce1
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 12:00:43 2011 +0300
server/red_worker: on_new_display_channel_client: push ack, cleanup
small cleanup patch, only functional change is sending a set ack message.
commit 0ed0b9e097470d42bea431d8e44a4a88c79f783d
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 11:31:28 2011 +0300
server/red_worker: red_current_add_equal: add dcc null checks
check for dcc!=NULL before adding to pipe in several places.
commit d1c848bf36fc91415f3590aeda1f6ac7ae093a8c
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 10:32:10 2011 +0300
server/reds: make reds_fill_channels return no sound channels for client > 1
At this point you can actually connect a second client without disconnecting the
first due to the sound channel doing the disconnect. Since sound has not
been multiple client enabled yet this is all that can be done.
commit 7cd55cf64fa8775be96d783f50fa0399e100a107
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 10:31:41 2011 +0300
server/reds: add RedsState.allow_multiple_clients (temp - add accessors too)
commit 59f20ef48ecfaa0f37173ad85c9e4db261a8e784
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 09:44:21 2011 +0300
server/red_worker: add cursor_channel_client_disconnect
makes RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT disconnect only a
single client.
commit 681d6b7f2cba6b6dce13abadbfa7795fc12a553b
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 09:43:35 2011 +0300
server/red_worker: remove forced disconnect on connect
commit 4a7ddc7f0d7d1cc43f1082f7972eb39f35f04fbe
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 24 13:39:41 2011 +0300
server/red_worker: split cursor pipe item from cursor item
Required to support multiple clients.
Also changes somewhat the way we produce PIPE_ITEM_TYPE_LOCAL_CURSOR. Btw,
I haven't managed to see when we actually produce such an item during my
tests.
Previously we had a single pipe item per CursorItem, this is impossible
with two pipes, which happens when we have two clients.
commit c43168f2374759b1d5d28b4477142a7ab6496c12
Author: Alon Levy <alevy at redhat.com>
Date: Fri Apr 22 23:05:08 2011 +0300
server/red_worker: move free from display_channel_send_item to _release_item
commit 464b6ce09d3ecf5aaf97a7367b063c461dece4b4
Author: Alon Levy <alevy at redhat.com>
Date: Sat Apr 23 09:35:09 2011 +0300
server/red_worker: red_worker_main: call red_handle_streams_timeout for all clients
commit 15ca892bff2bd74c9f8e4c07db7b6750cfc2a27c
Author: Alon Levy <alevy at redhat.com>
Date: Sat Apr 23 09:30:42 2011 +0300
server/red_worker: get_streams_timeout: go over all clients
commit 265aa7c70f24d96e81ad0bd8d994f35567fced43
Author: Alon Levy <alevy at redhat.com>
Date: Sat Apr 23 09:19:33 2011 +0300
server/red_worker: handle_dev_input RED_WORKER_MESSAGE_STOP: all clients
commit 7be0d680f0712ffdca98e379af690b9cfc05b88a
Author: Alon Levy <alevy at redhat.com>
Date: Sat Apr 23 09:15:49 2011 +0300
server/red_worker: handle_dev_destroy_primary_surface: clear all primary copies
commit 2b2bf86b7d9e75b3f3c493f95f40a7d25ec7362f
Author: Alon Levy <alevy at redhat.com>
Date: Sat Apr 23 09:11:13 2011 +0300
server/red_worker: handle_dev_destroy_surfaces: clear all surfaces
commit c0b3fd5a27540450c214cfe250d26eb4defa08ab
Author: Alon Levy <alevy at redhat.com>
Date: Fri Apr 22 23:14:20 2011 +0300
server/red_worker: handle_dev_destroy_surface_wait: all clients render state
commit 3206a9ff2e490ab0ef630c8731315e9c524e000c
Author: Alon Levy <alevy at redhat.com>
Date: Fri Apr 22 23:12:44 2011 +0300
server/red_worker: handle_dev_update: for all clients (checkme)
handle_dev_update does area_update, i.e. rendering to a surface (usually
the primary, surface 0) on request of the driver. Since we only use a single
canvas for each surface on the device memory (the rest are in host memory),
this patch may not really be required.
TODO: test without this patch.
commit d3b21b9f86eb602d69bb34afa7b911d8c54b36ed
Author: Alon Levy <alevy at redhat.com>
Date: Fri Apr 22 23:09:42 2011 +0300
server/red_worker: copy and free new surfaces after first client
commit ac7a8b5b04e87577938a004c7743727d28aa804f
Author: Alon Levy <alevy at redhat.com>
Date: Fri Apr 22 23:04:27 2011 +0300
server/red_worker: whitespace fixes
commit 676738cb2cb9c34417168d1c7cc376dd2b0f4dcd
Author: Alon Levy <alevy at redhat.com>
Date: Fri Apr 22 17:36:43 2011 +0300
server/red_worker: red_create_surface - check for dcc before sending messages
commit 901966c2c746cb19f4bdc08aafb258d698fb32bf
Author: Alon Levy <alevy at redhat.com>
Date: Fri Apr 22 17:36:16 2011 +0300
server/red_worker: tiny cleanups
commit af9a865c6676d6abe8a79ef75b60a7dfdf97ff05
Author: Alon Levy <alevy at redhat.com>
Date: Fri Apr 22 14:17:15 2011 +0300
server/red_worker: start using RENDER_FOREACH
commit 3f6e627c019677b82ebdfc75d7009a25d3429922
Author: Alon Levy <alevy at redhat.com>
Date: Thu Apr 21 22:21:36 2011 +0300
server/red_worker: add ref counting to RedDrawable
When we start having multiple clients each
drawable will be referenced by multiple clients, release happens when all
clients are done with it.
commit 573fdb4ba3d196939a4ec93be1ca82150f3ebaba
Author: Alon Levy <alevy at redhat.com>
Date: Wed Apr 13 09:42:35 2011 +0300
server/red_worker: introduce RedSurfaceReleaseInfo
with multiple clients any surface creation or deletion cleanup needs to
wait until all the clients have been sent the command, so add reference
counting to the create and destroy release calls.
Also introduces the SURFACES_FOREACH macro, a bit ugly due to the need
to update multiple variables and trying to do it without introducing any
function, so the macro can be used as a for loop head.
commit f2bff81c448ed4e70d5e65a93f30ca9cf3d81fc9
Author: Alon Levy <alevy at redhat.com>
Date: Wed Apr 13 09:24:31 2011 +0300
server/red_channel: introduce client ring in RedChannel
main_channel and red_worker had several locations that still accessed rcc
directly, so they had to be touched too, but the changes are minimal.
Most changes are in red_channel: drop the single client reference in RedChannel
and add a ring of channels.
We still are missing:
* surfaces copying / deleting in red_worker when a new client comes/goes
* remove the disconnect calls on new connections
commit 4af2fa6141ae3184842b80c9f52d18db87517c6d
Author: Alon Levy <alevy at redhat.com>
Date: Wed Apr 13 08:52:44 2011 +0300
server/red_channel: add pipe_size helpers
commit d34effd597dea0fa39dc9652759f3e748817b453
Author: Alon Levy <alevy at redhat.com>
Date: Wed Apr 13 00:35:20 2011 +0300
server/red_worker: remove more direct access to RedChannelClient.rcc
commit f2cec0daaac43a1ce40a2949dd61e709e5d7d2f2
Author: Alon Levy <alevy at redhat.com>
Date: Tue Apr 12 22:44:41 2011 +0300
server/red_worker: split display and cursor channels
Introduce DisplayChannelClient, CursorChannelClient, CommonChannelClient.
don't disconnect channel on client disconnect.
Move all caches to the ChannelClient's.
Remove reference counting of the channel - need to split this to a separate
patch. The rationalization for this:
/* TODO: Why do we reference count the listener?
* really - what's the lifecycle of a listener? isn't it from peer connection
* until removal? the drawable's etc. have a valid lifetime outside of this, but
* isn't the listener's lifetime exactly this?
* This was meant to allow deletion of the display_channel itself - but now
* we don't actually ever delete that.
* */
No new functionality introduced.
TODO: fix crash:
Still have the possibility of crashing if too many disconnections happen at
once. Noticed that this happens if we call disconnect with two different channel
clients pointing to the same channel. should make sure the channel destruction
happens from a single thread? should only happen from main thread. check
by printing pthread_self.
commit 28d0a4b8dcb28df9d983642549ee9037d362789e
Author: Alon Levy <alevy at redhat.com>
Date: Tue Apr 12 14:27:51 2011 +0300
server/red_worker: fix typo (lats_send_time)
commit 4b45b0cf4c2bf580b0d3420aa6977aaea5d9e143
Author: Alon Levy <alevy at redhat.com>
Date: Tue Apr 12 14:24:10 2011 +0300
server/red_worker: make stat_now static
commit e71c085d7f25aefa129f33df3f8d11d1639eac41
Author: Alon Levy <alevy at redhat.com>
Date: Thu May 5 12:49:35 2011 +0300
server/red_worker: cleanup
commit 80c9fd164a6ff73475cc6a8aef02301c64acb2a8
Author: Alon Levy <alevy at redhat.com>
Date: Thu May 5 12:46:21 2011 +0300
server/red_worker: split RedRender from RedWorker
Split the operations list, the surfaces and the streams out from RedWorker
into a RedRender struct that has a reference to RedWorker.
This patch is technical, changing signatures to use RedRender *render
instead of RedWorker *worker, and changing s/worker/worker->surfaces/.
In later patches there will be a multiplicity of RedRender:
0 | 1
n >=1 | n
The first instance is embedded in RedWorker. The later are embdedded
in the DisplayChannelClient which has not been introduced yet.
The surfaces backing store needs to be separate for the main RedRender
instance and for the rest. For the main it needs to be vram, since
the guest will read from there after an UPDATE_AREA. For the others
it will be host memory.
A multiplicity of rendering trees and surfaces makes having a separate
pipe easy, since we can replace a number of operations in the pipe with
their equivalent without effecting the other clients. Such a replacement
may require rendering the operations, so it requires the surfaces to be
in sync with the tree for that client.
It might be possible to avoid some of this overhead later - in particular,
possibly having groups of clients associated with the same RedRender, and
only create a copy on change. The current implementation is the simplest,
and it doesn't cost anything extra for a single client.
Many function signatures are changed already to use RedRender as the first
parameter instead of using worker, this is in preparation for the next patches
where RedRender instances multiply.
commit 4b2a092aa789c1c06485679c265b886bfc4ef686
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 23:58:52 2011 +0300
server/smartcard: support multiple clients
each client supplying a smartcard channel gets it's own smartcard. If
there are not enough smartcards provided by the server (read: qemu)
then it will be as though there are none.
currently disabled - later patches that enable smartcard don't make
this channel available to any but the first client.
commit 3a18cad77b345822db679604fc0f691a7d0812c5
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 23:51:14 2011 +0300
server/red_tunnel_worker: trivial multi client support
s/TunnelChannel/TunnelChannelClient/
That's about it. this is probably the wrong way to do it. Not tested
at all. What do we want, a separate interface per client? same interface
for all clients? probably the later. This doesn't do that. Not tested,
so probably doesn't even work.
changes red_channel_pipe_item_is_linked to red_channel_client_pipe_item_is_linked,
since tunnel channel is the only user, must be done in patch to not break compilation.
commit 8f2f936f73cb342df9db3bbcc160269ce82cea65
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 22:51:54 2011 +0300
server/inputs_channel: support multiple clients
from server events are broadcast - leds change. The rest is client
to server, so it is just passed on.
commit 3ef358c0913b85a6336a953ac1c36af77daf753c
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 22:29:58 2011 +0300
server/main_channel: support multiple clients
The main channel deals with connecting new clients, announcing mouse mode
changes, and the agent channel. The implementation is currently done without
any changes to the protocol, so everything has to be either broadcast or
to a specific client.
channels list - specific client
mouse mode - broadcast
agent - broadcast
notify - broadcast (should have two modes, and use the appropriate)
Notable TODOs:
* migration testing
* agent tokens are wrongly sent (or did I fix that? check)
commit e70635612af8d4970035d101d1450ff8301bacf8
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 21:44:16 2011 +0300
server/red_channel: introduce pipes functions
Introduce functions to add (via producer method) the same item to multiple
pipes, all for the same channel.
Note: Right now there is only a single channel, but the next patches will do the
per-channel breakdown to channel and channel_client before actually introducing
a ring in RedChannel, this makes it easier to make smaller changes - the
channel->rcc link will exist until removed in the ring introducing patch.
commit b8ab4d4f4a72a4fbfdce2b83f4201cafc502452c
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 21:42:05 2011 +0300
server/red_channel: ignore error if already shutdown
on red_channel_peer_on_incoming_error, if we are already shutdown, do not
call the channel's error handler. Since the channel has been shutdown, we
assume this is a second or later error, and handling has already occured.
commit 7be788351d7a7ea6bb22ec0a51a5950db44619d6
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 20:58:01 2011 +0300
server/main_channel: move connection_id from reds
Expose additional api to find a client given a connection_id. The connection_id
is first set when the first channel connects, which is the main channel.
It could also be kept in the RedClient instead, not sure.
TODO:
multiple todo's added for multiclient handling. I don't remember why
I wrote them exactly, and besides if I did any migration tests. So: TODO.
commit 9bdd72e6c73d8d4ab7a5e77f37e0d6cc55b266ac
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 18:54:51 2011 +0300
server/main_channel: move ping here from reds.
cleanup only. Note that the ping function is half used since the opt parameter
stopped being called with anything but NULL, should be returned at some point,
specifically when we drop the 250kbyte ping on start and do a continuous check
for latency and bandwidth.
See:
81945d897 - server: add new vd interface QTerm2Interface, Yaniv Kamay
introducing the usage of ping with a non NULL opt
3f7ea8e7a - zap qterm interfaces, Gerd Hoffman
removing it
commit c41b6271d155bd14218fbe486880e1c29eb8ce15
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 10 21:11:20 2011 +0300
server/main_channel: move latency and bitrate to channel client
They were globals before. This introduces api for other channels
to query the low bandwidth status. The queries themselves are still done
from the wrong context (channel and not channel client) but that's because
the decoupling of channel and channel client will be done in the following
patches.
Note that snd_worker.c got two copied function declarations that belong to
main_channel.h but can't be easily dragged into snd_worker.c since it still
uses it's own RedChannel struct.
commit 9060225d11c4d18ae9520e67a324f9b84df0a561
Author: Alon Levy <alevy at redhat.com>
Date: Mon Apr 11 12:44:00 2011 +0300
server: Add RedClient
That means RedClient tracks a ring of channels. Right now there will be only
a single client because of the disconnection mechanism - whenever a new
client comes we disconnect all existing clients. But this patch adds already
a ring of clients to reds.c (stored in RedServer).
There is a known problem handling many connections and disconnections at the
same time, trigerrable easily by the following script:
export NEW_DISPLAY=:3.0
Xephyr $NEW_DISPLAY -noreset &
for ((i = 0 ; i < 5; ++i)); do
for ((j = 0 ; j < 10; ++j)); do
DISPLAY=$NEW_DISPLAY c_win7x86_qxl_tests &
done
sleep 2;
done
I fixed a few of the problems resulting from this in the same patch. This
required already introducing a few other changes:
* make sure all removal of channels happens in the main thread, for that
two additional dispatcher calls are added to remove a specific channel
client (RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT and
RED_WORKER_MESSAGE_DISPLAY_DISCONNECT_CLIENT).
* change some asserts in input channel.
* make main channel disconnect not recursive
* introduce disconnect call back to red_channel_create_parser
The remaining abort is from a double free in the main channel, still can't
find it (doesn't happen when running under valgrind - probably due to the
slowness resulting from that), but is easy to see when running under gdb.
commit e8ebc973e61e2076d9bbb943bddd56915ef3a9a8
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 10 21:51:58 2011 +0300
server/main_channel+reds: make main_channel_init return MainChannelClient
This makes it easier to introduce RedClient in the next patch.
commit 4eb72a10d72a1fcb94b8f24523e15aedaad1f1c4
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 10 20:17:39 2011 +0300
server/red_worker: release PIPE_ITEM_TYPE_VERB in display channel
We send a SPICE_MSG_DISPLAY_MARK verb.
commit 2c9a0e3a1c38316b443de7bb0bf968256f8bc510
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 10 20:03:11 2011 +0300
server/red_client: clear pipe on disconnect
commit 7a704354458acb39b4261dda60f3ee9a73d3058f
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 10 20:02:50 2011 +0300
server/red_channel: workaround for fast client disconnect bug (TODO - real fix)
commit 0604e216b4f06561e4d902a58a09eb19f235d0f5
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 10 18:18:11 2011 +0300
server/main_channel: use MainChannel in sig
use MainChannel* instead of Channel* for a many functions in main_channel.h
(affects main_channel.c and reds.c).
some one liner fixes are hidden in here too.
commit dc25b811d03c1a83b4ed70dd53630a41d324f763
Author: Alon Levy <alevy at redhat.com>
Date: Sat Apr 2 12:54:52 2011 +0300
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).
commit 9791a932c776ac55bad3d9e9d53304fa1a432e93
Author: Alon Levy <alevy at redhat.com>
Date: Mon Nov 22 16:56:58 2010 +0200
server/red_worker: introduce {display,cursor}_is_connected
Instead of checking for worker->{display,cursor}_channel directly.
commit d9a417812b140542bd219ba228233e1b09e9fa22
Author: Alon Levy <alevy at redhat.com>
Date: Sat Nov 13 13:23:02 2010 +0200
server/red_channel (all): introduce RedChannelClient
This commit adds a RedChannelClient that now owns the stream connection,
but still doesn't own the pipe. There is only a single RCC per RC
right now (and RC still means RedChannel, RedClient will be introduced
later). All internal api changes are in server/red_channel.h, hence
the need to update all channels. red_worker.c is affected the most because
it makes use of direct access to some of RedChannel still.
API changes:
1. red_channel_client_create added.
rec_channel_create -> (red_channel_create, red_channel_client_create)
2. two way connection: rcc->channel, channel->rcc (later channel will
hold a list, and there will be a RedClient to hold the list of channels
per client)
3. seperation of channel disconnect and channel_client_disconnect
commit 80e3228a2eaf5fbb1a126c0f030cb7178b4afbf1
Author: Alon Levy <alevy at redhat.com>
Date: Thu Mar 24 18:17:17 2011 +0200
server/red_worker: drop red_pipe_add_tail, use red_channel_pipe_add_tail
The only difference between them being that the later also does a push.
I don't believe that to be a problem, but if it does I can always introduce
a push'less version.
commit 92d09ef5f3d654da7a04be2a7545788446b8f388
Author: Alon Levy <alevy at redhat.com>
Date: Thu Mar 24 16:41:02 2011 +0200
server/red_channel: renames to use _proc postfix consistently
rename types - we use _proc suffix mostly to indicate function pointer types, use it
for some function pointers that were missing it.
s/channel_handle_migrate_flush_mark/channel_handle_migrate_flush_mark_proc/
s/channel_handle_migrate_data_get_serial/channel_handle_migrate_data_get_serial_proc/
s/channel_handle_migrate_data/channel_handle_migrate_data_proc/
commit baf6a595cff2e3c87ad1c3418fcfba20bd3a656a
Author: Alon Levy <alevy at redhat.com>
Date: Sun Apr 10 16:21:15 2011 +0300
server/main_channel.c: set NET_TEST_STAGE_INVALID=0 explicitly (TODO - the rest)
should change all the enums that don't explicitly set their first value to 0.
More information about the Spice-commits
mailing list