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
