[Spice-devel] Help with solving a thread safety issue

[Jeremy White]

This thread veered; I'd like to bring it back, if I can.

I've got a clear case of thread unsafety in XSpice. 
spice_server_playback_put_samples is called from a different thread than 
the main thread.  If the main thread calls 
main_dispatcher_handle_mm_time_latency while we're putting samples, very 
bad things result.  (I get a spin loop in the X server, mostly; there is 
a fairly easy way to get snd_worker.c to infinite loop in 
snd_send_data() with a little help from a malicious thread; if n != 0 at 
the end of that loop, and  spice_marshaller_fill_iovec returns 0).

This is a bug, and I think it's well understood (even if the best fix is 
not).

We were hoping that I may have also exposed an issue in the qemu case, 
but the jury is out on that.

We've got a lot of complaints of video/audio sync, and general video 
quality, but nothing that struck me as fitting the result I would expect 
from this bug.  So I think they are unrelated issues.

As an aside, to any of the people suffering with audio/video issues, 
that seem to be clear regressions, if any of you have the ability to do 
a git bisect, that would be a very powerful way to help us understand 
that issue.

But, back to *my* thread <grin>:

I was hoping that someone who knew qemu better than I could answer the 
question:  does the qemu audio processing loop run in it's own thread? 
The equivalent call in qemu/spiceaudio.c (i.e. the call to 
spice_server_playback_put_samples) happens in qemu/audio/spiceaudio.c. 
That, in turn, appears to be called from run_out/then timer_run in 
qemu/audio/aduio.c.  That timer seems to be established by a call to 
timer_new_ns in audio/audio.c, which devolves into a timer_init call. 
But, afaict, timer_init just sets up the structure, and doesn't actually 
start anything running.

I'm hoping a qemu expert can tap me with a clue bat and just help me 
answer that question.

Cheers,

Jeremy