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
