[pulseaudio-discuss] [PATCH 09/11] pulsecore: memexport/memimport: Introduce memfd blocks support

[Tanu Kaskinen]

On Sun, 2015-09-27 at 22:56 +0200, Ahmed S. Darwish wrote:
> > Do you already have an idea how to fix it? Could we send
> > the fd just once during the connection set-up phase, and always use
> > that fd from then on?
> > 
> 
> Yup.
> 
> We will emulate what the posix SHM code is currently doing, which
> resembles what you're proposing above.
> 
> When a PA endpoint creates a memfd region, it attaches a randomly
> generated ID to this memfd region. When a memblock inside this memfd
> area is sent to the other end using pstreams, we also send this
> random ID beside the memfd file descriptors.

Is randomness really necessary? I don't know for sure why the current
SHM code uses random ids, but I'd guess it's because otherwise
malicious users or programs could create tons of files in /dev/shm with
the deterministic name generation algorithm, which would slow down
PulseAudio's own SHM file creation. memfds don't have a global
namespace, so this problem doesn't exist.

> This way, the receiving end (as done with posix SHM) will use a hash
> table to store these ids. If the ID matches, we won't create a new
> memfd "memimport_segment" and just use the existing one and its
> already open and mapped file descriptor. If nothing matches, we'll
> use the sent fds for opening and mapping, up to a max of 16.

If the fd is sent with every memblock, we'd still have to close the
received fd for every memblock. Is that something that can cause
significant overhead?

> Thanks a lot for your reviews and kind words :-)
> 
> Honestly, the PA code, and PA itself, was very foreign at first. Thus
> to build a coherent mental picture, I've followed up with the code and
> wrote these documents here:
> 
>     https://a-darwish.gitbooks.io/diary-of-pulseaudio-developement/content/what_are_mempools.html
>     https://a-darwish.gitbooks.io/diary-of-pulseaudio-developement/content/memory_chunks_and_memblockq.html
>     https://a-darwish.gitbooks.io/diary-of-pulseaudio-developement/content/shm_file_sharing.html
>     ..
>     https://a-darwish.gitbooks.io/diary-of-pulseaudio-developement/content/logind_sessions_supportv2.html
> 
> Maybe one day we can polish these and transform them into a coherent
> introductory guide for PulseAudio development ;-)

Sure, if you have the motivation. Probably such guide wouldn't be kept
up to date, though. But in any case, at least we can add a link here:

https://wiki.freedesktop.org/www/Software/PulseAudio/Documentation/Developer/

That page already has the "Writing Modules" link, which points to a
kind of similar attempt at documenting the server internals. It doesn't
have much content, and hasn't been updated since 2008 :) I wrote it
when I was new to PulseAudio myself.

-- 
Tanu