[pulseaudio-tickets] [Bug 45643] padsp wrapper is racy at startup

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=45643

--- Comment #5 from Arun Raghavan <arun at accosted.net> 2012-03-15 00:02:14 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > This looks a bit odd. fd_info_new(), which is called from dsp_open(), only returns when the context is READY.
> 
> Right. Let's consider the following code:
> 
> dsp_open calls:
>     fd_info_new()
>     ...
>     i->io_event = api->io_new(api, i->thread_fd, i->io_flags, io_event_cb, i);
> 
> Before any IO occurs the state s READY, and it's seen in trace, but later.
> When io occurs 'io_event_cb' is triggered (callback called asynchronously,
> right?)

Yes, this registers an async callback when some I/O occurs.

> Let's looks at where it does there:
> io_event_cb:
>     // no idea what it does, but looks like it unblocks clients
>     pa_threaded_mainloop_signal(i->mainloop, 0); 

This is standard POSIX condition semantics -- the main thread is being told
that some condition it is waiting for has been met.

>     // and then starts actual stream initialization
>     if (flags & PA_IO_EVENT_INPUT) {
>         if (!i->play_stream) {
>             if (create_playback_stream(i) < 0)
> 
> create_playback_stream:
>     // stream _DROPS_ initialization state down to: PA_STREAM_UNCONNECTED and
> then to PA_STREAM_CREATING
>     i->play_stream = pa_stream_new(i->context, stream_name(), &i->sample_spec,
> NULL);

This creates a new stream, doesn't mess with an existing stream.

This could go faster if you have some sort of quick test case for me to
reproduce the issue locally.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.