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

[Peter Meerwald]

> > ... 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?

that's the idea; I am aware of the problem but have no good argument yet 
(besides: seems to work :)

this patch is crucial to make good benefit from the send queue peeking

p.

> > ---
> >   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 */
> >
> 
> 

-- 

Peter Meerwald
+43-664-2444418 (mobile)