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