[pulseaudio-discuss] Expand the simple API?

[Tanu Kaskinen]

On Wed, 2013-03-20 at 09:32 +0100, David Henningsson wrote:
> On 03/20/2013 08:57 AM, Tanu Kaskinen wrote:
> > On Tue, 2013-03-19 at 13:20 +0100, Thomas Martitz wrote:
> >> Am 19.03.2013 10:56, schrieb Tanu Kaskinen:
> >>> I'd be OK with adding pa_simple_writable/readable_size(). I believe the
> >>> multi-threading aspect of adding the write/read callbacks unavoidably
> >>> makes writing applications not-simple, so the simple API probably
> >>> shouldn't have those callbacks.
> >>>
> >>
> >> It's not unlikely that an application that uses blocking or polling
> >> methods uses an extra thread for that, which it wouldn't do if it could
> >> use the callback method. So in this case the callback would simplify the
> >> application, because the multi threading aspect is not in the
> >> application logic but in pulseaudio. I don't know how common this case
> >> is, but I would expect it's rather common.
> >
> > The applications would still need to be aware of the threading.
> > pa_simple_read/write() is expected to be done from the main thread, so
> > the application necessarily needs to implement some communication method
> > between the two threads.
> 
>  From what I can see, there is no such restriction of the simple API. It 
> does not have a concept of a "main thread", so as long as you don't call 
> into the simple API from two threads at the same time you should be just 
> fine, e g, it would be perfectly valid to do pa_simple_new in one 
> thread, and later call pa_simple_write from another thread.

pa_simple_write() calls pa_threaded_mainloop_wait(), and
pa_threaded_mainloop_wait() has this assertion:

pa_assert(!m->thread || !pa_thread_is_running(m->thread) || !in_worker(m));

The in_worker() check will fail, if pa_simple_write() was called from
the callback context.

-- 
Tanu