qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KVM call minutes 2013-01-29


From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call minutes 2013-01-29
Date: Tue, 29 Jan 2013 10:47:29 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Paolo Bonzini <address@hidden> writes:

> Il 29/01/2013 16:41, Juan Quintela ha scritto:
>> * Replacing select(2) so that we will not hit the 1024 fd_set limit in the
>>   future. (stefan)
>> 
>>   Add checks for fd's bigger than 1024? multifunction devices uses lot
>>   of fd's for device.
>> 
>>   Portability?
>>   Use glib?  and let it use poll underneath.
>>   slirp is a problem.
>>   in the end loop: moving to a glib event loop, how we arrive there is the 
>> discussion.
>
> We can use g_poll while keeping the main-loop.c wrappers around the glib
> event loop.  Both slirp and iohandler.c access the fd_sets randomly, so
> we need to remember some state between the fill and poll functions.  We
> can use two main-loop.c functions:
>
> int qemu_add_poll_fd(int fd, int events);
>
>   select: writes the events into three fd_sets, returns the file
>   descriptor itself
>
>   poll: writes a GPollFD into a dynamically-sized array (of GPollFDs)
>   and returns the index in the array.
>
> int qemu_get_poll_fd_revents(int index);
>
>   select: takes the file descriptor (returned by qemu_add_poll_fd),
>   makes up revents based on the three fd_sets
>
>   poll: takes the index into the array and returns the corresponding
>   revents
>
> iohandler.c can simply store the index into struct IOHandlerRecord, and
> use it later.  slirp can do the same for struct socket.
>
> The select code can be kept for Windows after POSIX switches to poll.

Doesn't g_poll already do this under the covers for Windows?

Regards,

Anthony Liguori

>
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]