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
