Comment 5 for bug 853560

Some notes:

#9 0x00007f5a4c6b096b in pa_fdsem_after_poll (f=0x25d3a90) at pulsecore/fdsem.c:315
        __func__ = "pa_fdsem_after_poll"
        __PRETTY_FUNCTION__ = "pa_fdsem_after_poll"
#10 0x00007f5a4c6a08fc in pa_asyncq_write_after_poll (l=0x25d3250) at pulsecore/asyncq.c:319
        __func__ = "pa_asyncq_write_after_poll"
        __PRETTY_FUNCTION__ = "pa_asyncq_write_after_poll"

#2 0x00007f5a4c6b0970 in pa_fdsem_after_poll (f=0x25d3a90) at pulsecore/fdsem.c:315
        __func__ = "pa_fdsem_after_poll"
        __PRETTY_FUNCTION__ = "pa_fdsem_after_poll"
#3 0x00007f5a4c6a08fc in pa_asyncq_write_after_poll (l=0x25d3250) at pulsecore/asyncq.c:319
        __func__ = "pa_asyncq_write_after_poll"
        __PRETTY_FUNCTION__ = "pa_asyncq_write_after_poll"

I assume, both threads should not call this simultaneously on the same object, which is module-null-sink's thread_mq->outq. The outq writes in the thread and reads from the main thread. Therefore it seems like the main thread should not call write_after_poll.