[PATCH 1/2] thread_mq supports a mainloop as thread/consumer

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

 



On Mon, 2013-07-22 at 01:49 +0200, Alexander Couzens wrote:
> Signed-off-by: Alexander Couzens <lynxis at fe80.eu>
> ---
>  src/pulsecore/thread-mq.c | 92 +++++++++++++++++++++++++++++++++++++++++++----
>  src/pulsecore/thread-mq.h |  5 ++-
>  2 files changed, 89 insertions(+), 8 deletions(-)

I didn't read the patch yet, but I realized, after seeing a
pa_sink_set_rtpoll() call in the Bluetooth code, that there is code that
depends on the IO thread polling being implemented with rtpoll. For
example, module-rtp-recv doesn't create a sink itself, but it connects
to an external sink (could be your tunnel sink) and expects that it can
use sink->thread_info.rtpoll.

This needs to be resolved somehow at some point (not now, please
concentrate on implementing the tunnel module). I really would like to
use pa_mainloop_api as the interface for interacting with all event
loops, including the IO thread event loops. I think it should be
investigated whether it's feasible to implement pa_mainloop_api with
pa_rtpoll as the backend.

-- 
Tanu



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux