Unix FD Passing
Lennart Poettering
mzqohf at 0pointer.de
Wed May 20 12:32:33 PDT 2009
On Fri, 15.05.09 21:49, Havoc Pennington (hp at pobox.com) wrote:
> > 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.
This large preallocation only happens once per connection, not again
for each message. When a message actually needs fds they are removed
from that preallocated array and added into the message in a properly
sized array. That array is then even later reused, following the
usual message caching logic.
So, while the large preallocation certainly sucks, it's only once per
connection. Shouldn't be too bad.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus
mailing list