It seems that the intention was to create create write_thread_event on thread_mainloop instead of main_mainloop (the first parameter of io_new() is thread_mainloop, io_free() is called on thread_mainloop etc.). As long as both mainloops are implemented with pa_mainloop, this bug has no effect on behaviour, because the io_new() implementation is the same. And ideed, with the current code base both mainloops are always pa_mainloops. However, when the tunnel-new modules switches to pa_rtpoll as the pa_mainloop_api provider, this bug would cause problems. --- src/pulsecore/thread-mq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pulsecore/thread-mq.c b/src/pulsecore/thread-mq.c index f4489ac..ed4ab6a 100644 --- a/src/pulsecore/thread-mq.c +++ b/src/pulsecore/thread-mq.c @@ -111,7 +111,7 @@ void pa_thread_mq_init_thread_mainloop(pa_thread_mq *q, pa_mainloop_api *main_ma pa_assert_se(pa_asyncmsgq_read_before_poll(q->outq) == 0); pa_asyncmsgq_write_before_poll(q->outq); pa_assert_se(q->read_main_event = main_mainloop->io_new(main_mainloop, pa_asyncmsgq_read_fd(q->outq), PA_IO_EVENT_INPUT, asyncmsgq_read_cb, q)); - pa_assert_se(q->write_thread_event = main_mainloop->io_new(thread_mainloop, pa_asyncmsgq_write_fd(q->outq), PA_IO_EVENT_INPUT, asyncmsgq_write_outq_cb, q)); + pa_assert_se(q->write_thread_event = thread_mainloop->io_new(thread_mainloop, pa_asyncmsgq_write_fd(q->outq), PA_IO_EVENT_INPUT, asyncmsgq_write_outq_cb, q)); pa_asyncmsgq_read_before_poll(q->inq); pa_asyncmsgq_write_before_poll(q->inq); -- 2.9.3