[pulseaudio-discuss] [PATCH RFCv3 21/51] pstream: Don't call defer_enable() on SHMRELEASE

[David Henningsson]

On 2014-11-05 00:26, Peter Meerwald wrote:
> From: Peter Meerwald <p.meerwald at bct-electronic.com>
>
> ... in order to increase the chance that SHMRELEASE will be combined
> with some other message; SHMRELEASE gets into the send queue, but
> the mainloop is not notified about it

...the idea being that shmrelease is not crucial to get any time soon, 
it's just about reclaiming memory anyway. But is there a risk that they 
never get sent? E g, if the stream gets corked, stopped, runs out of 
data, or something, and now we just have all of these waiting in the 
send queue, but there is no reason to send anything else, so they'll be 
waiting there indefinitely?

>
> Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net>
> ---
>   src/pulsecore/pstream.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/pulsecore/pstream.c b/src/pulsecore/pstream.c
> index e1b84c6..88bf5d4 100644
> --- a/src/pulsecore/pstream.c
> +++ b/src/pulsecore/pstream.c
> @@ -459,7 +459,11 @@ void pa_pstream_send_release(pa_pstream *p, uint32_t block_id) {
>   #endif
>
>       pa_queue_push(p->send_queue, item);
> -    p->mainloop->defer_enable(p->defer_event, 1);
> +    /* Don't call defer_enable() to increase the chance that

"Don't call defer_enable() here. This increases the chance that"

> +     * the SHMRELEASE item can be combined with some other
> +     * item and sent together in one mini buffer.
> +     * p->mainloop->defer_enable(p->defer_event, 1);
> +     */
>   }
>
>   /* might be called from thread context */
>

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic