On 07/26/2012 09:16 AM, Kevin Wolf wrote:
Am 26.07.2012 15:13, schrieb Eric Blake:
On 07/25/2012 09:21 PM, Corey Bryant wrote:
On 07/25/2012 03:25 PM, Eric Blake wrote:
On 07/25/2012 02:22 AM, Kevin Wolf wrote:
Hm, not a nice interface where qemu_close() needs the filename and
(worse) could be given a wrong filename. Maybe it would be better to
maintain a list of fd -> fdset mappings in qemu_open/close?
I agree, I don't really like it either.
We already have a list of fd -> fdset mappings (mon_fdset_fd_t ->
mon_fdset_t). Would it be too costly to loop through all the
fdsets/fds
at the beginning of every qemu_close()?
I don't think so. qemu_close() is not a fast path and happens almost
never, and the list is short enough that searching it isn't a problem
anyway.
I agree - just do the loop to do the reverse lookup yourself, rather
than making qemu_close() have a different signature than close().
Great, I'll do this then.
You may want an optimization of using a bitset for tracking which fds
are tracked by fdset in the first place, so that the fast path of
qemu_close() will be a check against the bitset to see if you even have
to waste time on the reverse lookup in the first place. The bitset will
typically be small (bounded not only by the maximum possible fd, but
further by the fact that we don't usually open that many fds in the
first place), but I'm not sure if you can get away with static sizing.
Premature optimisation, in my opinion. The list is really small.
Kevin
I'll probably hold off on any optimisation at this point, but I can
revisit it in the future if it's needed.
--
Regards,
Corey
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list