Re: Some notes on threading and reference counting on spice-server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2017-08-25 at 13:07 -0400, Frediano Ziglio wrote:
> How Spice handle threading
> --------------------------
> 
> Lot of code run in a single thread.
> 
> Qemu usually calls Spice from the same thread except on call backs to
> code already run in different threads.
> 
> Channel run mostly on a single thread except on creation and
> destroying which MUST be done in the main thread.  Lot of Channels
> run
> on the main thread but currently CursorChannel and DisplayChannel can
> be run from within a thread created by Worker.  Note that different
> CursorChannel/DisplayChannel (they differ by id) run in separate
> Worker threads.
> 
> ChannelClient runs in the Channel thread. Ever creation is done
> in the same thread while destruction can happen in different
> phases.
> 
> RedClient is bound to ChannelClients that can be in separate threads.
> Is one of the cases where mutexes are used.
> 
> Another important aspect of dealing with multiple threads are the
> dispatchers.  Dispatchers are used to send messages/request from one
> thread to another.  The main dispatcher is used to send requests to
> the main thread.  The Qxl uses a dispatcher to send requests to the
> Worker which will forward to DisplayChannel/CursorChannel.
> 
> Client may call some ChannelClient functions using some callbacks
> registered inside ClientCbs. Usually these callbacks are functions
> that
> does the job directly if the Channel is running in the main thread or
> they use a dispatcher to do the job in the right thread. Currently
> there are 3 callbacks: connect, disconnect and migrate. Connect and
> migrate are asynchronous (the job is done while the current thread is
> doing something else) while disconnect is synchronous (the main
> thread
> will wait for termination).
> 
> Reference counting and owning 
> -----------------------------
> ->    pointer 
> --->  pointer with owning (mostly GObject ref counting)
> 
> ChannelClient -> Client
> Client ---> ChannelClient
> Client -> MainChannelClient
> 
> ChannelClient ---> Channel
> Channel -> ChannelClient
> 
> In this case the "real" owner is the TCP connection.  When a
> disconnection is detected the links Channel -> ChannelClient and
> Client ----> ChannelClient are removed causing possibly ChannelClient
> to be released (the main owner of ChannelClient is Client).  When
> MainChannelClient is disconnected it disconnects all ChannelClients
> connected to the same Client
> Who owns Client? Client is released when the MainChannelClient
> attached is disconnected. In this case a request is scheduled in the
> main thread (even if MainChannelClient run on the main thread too)
> and
> red_client_disconnect is called which calls red_client_destroy which
> use g_object_unref to free the object.
> Where is freed the MainChannelClient? On disconnection like other
> channel clients, currently before Client which will have a dandling
> pointer.
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/spice-devel




Nice summary, thanks. Maybe we should add some documentation based on
this to the spice repository under docs/? 

Jonathon

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]