Unix FD Passing

Havoc Pennington hp at pobox.com
Fri May 15 18:49:20 PDT 2009


Hi,

On Fri, May 15, 2009 at 6:54 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
>> I would guess the most common number of fds to pass is 1, so
>> allocating 1024 seems a little harsh. Though it is nice to avoid
>> realloc headaches, which are error-prone. :-/
>> (cosmetic: again, avoid test and assign on same line)
>
> For the reasons pointed out earlier we cannot really do the usual
> realloc() logic here: the kernel APIs simply drop fds when there is no
> space in the fd array we pass to it. And we cannot get them back and
> we cannot retry with a bigger buffer. Which means that we need to pass
> an fd array to it that is as big as it could ever get right from the
> beginning. That certainly sucks. I tried to minimize impact though by
> allocating that array as late as possible and only when fd passing is
> really negotiated. (which isn't worth much though, since in I guess in
> 99% of all cases fd passing *will* be negotiated.)

Seems like the key optimization here would be to keep recycling the
same large fd allocation over and over until we get a message that
actually uses it. Or the "message cache" thing in dbus-message.c may
in effect do this already, I guess, so no extra effort required.

Havoc


More information about the dbus mailing list