[pulseaudio-discuss] [PATCH 00/11] Introduce memfd support

[Ahmed S. Darwish]

On Fri, Jan 08, 2016 at 02:10:35PM +0100, David Henningsson wrote:
> On 2016-01-02 21:04, Ahmed S. Darwish wrote:
> > On Mon, Sep 28, 2015 at 10:47:09AM +0200, David Henningsson wrote:
> > >
> > > The per-client memfd should be set up by the server at SHM negotiation time
> > > (and sealed, but you've said that's a future patch set). Then send a packet
> > > with the memfd as ancil data (or extend PA_COMMAND_ENABLE_SRBCHANNEL, if
> > > that's simpler). This packet should also have an ID that identifies the
> > > memfd.
> >
> > I'm having a problem in this part. By doing as said above, aren't we
> > limiting the pstream connection to send memblocks only from a _single_
> > memfd-backed pool?
> >
> > Imagine the following:
> >
> > // PA node 1
> > pa_pstream_send_memblock(p, memblock1);    // memblock1 is inside pool1
> > pa_pstream_send_memblock(p, memblock2);    // memblock2 is inside pool2
> >
> > If pool1 and pool2 are backed by different memfd regions, how would the
> > above suggestion handle that case?
> 
> Hmm, to ask a counter question; why would you put them in different pools in
> the first place? Why would you need more than one pool per pstream?
>

Maybe I'm utterly confused, but don't we have different pools, backed
by different SHM files, even for the simplest case of a PA audioplayer
client?

That is:

- One pool for the srbchannel communication
  Created by server after SHM negotiation, read-write
  protocol-native.c, setup_srbchannel()
  unique, new, SHM file for this pool

- One pool for audio data from client to server
  Created by the client, read-only
  context.c, pa_context_new_with_proplist()
  unique, new, SHM file for this pool

But in the connection between client and server, we have only a one
and only pstream:

- From the client side, it's at pa_context->pstream

- From the server side, it's at pa_native_connection->pstream

So if I'm going to send _only one_ memfd fd at SHM negotiation time
(or piggyback it with PA_COMMAND_ENABLE_SRBCHANNEL), how am I going
to handle it when client send audio data over pstream, which is
backed by a different memfd file from the one used by srbchannels?

Thanks a lot,

P.S. Quickly sending memfd fds at srbchannel initiation time was the
early prototype I've used for this patch series long time ago. The
reason the final implementation differed (and got bigger) was to
support memfds, _transparently_, for all the pools in the system.

Pools which are using different SHM files by design.

That is, 1) the srbchanel mempool, 2) the client mempool, and 3)
the "pa_core" mempool used for sending recorded audio

Regards,

-- 
Darwish
http://darwish.chasingpointers.com