[Spice-devel] [PATCH spice] Provide thread safety between spice_server_playback_put_samples and snd_set_playback_latency.

[Marc-André Lureau]

Hi

----- Original Message -----
> >
> > Is this difficult to solve? It seems the thread is reading from a fd and
> > pushing to spice server. Couldn't this be done from X main loop?
> 
> Yes, that may be possible.  There are some tricks with the timing that
> may make that challenging (e.g. we need to feed audio at regular
> intervals).  I also have the sense that the original implementation was
> done that way, and we changed to this approach for some good reason that
> I can not currently recall :-/.
> 
> I will dig a bit deeper and report back.
> 
> >
> >     This patch uses a mutex to prevent such collisions.
> >
> >
> > Is the mutex supposed to protect the whole SndChannel struct?It seems
> > there are various code path that could be called with or without the
> > lock held (snd_playback_send callback, for example). I would rather move
> > the protected bits into a substructure, and make sure only access is
> > made with the lock.
> 
> Fair enough; the patch as written was arguably more a proof of concept
> than a full implementation.  It did patch the known risk area, but is
> arguably not fully rigorous.
> 
> >
> > But I think we are going in a dangerous place if we start making spice
> > server MT-safe api
> 
> I think that was the key question I was trying to get at.  I see some
> evidence that there has been some effort made, and I wanted to get a
> sense for the longer term plans in this respect.

Hmm, you are thinking about the dispatcher? I am not sure it was meant to be able for the client to call from different threads, but simply to be able to communicate with the worker thread. There are also some internal struct protected to be able to share among multiple worker threads (cache & glz).  And then there are also locks for the worker thread to be able to do its job with shared structs (client etc). But this is just a quick review, I may be wrong.

cheers