Messages in this thread | | | Date | Thu, 20 Aug 2009 19:56:05 +0200 | From | Paolo Bonzini <> | Subject | Re: [PATCH 0/2] eventfd: new EFD_STATE flag |
| |
On 08/20/2009 07:44 PM, Davide Libenzi wrote: > On Thu, 20 Aug 2009, Avi Kivity wrote: > >> On 08/20/2009 07:20 PM, Davide Libenzi wrote: >>> >>> I briefly looked at this while in vacation, although I did not reply >>> hoping the horrible feeling about this code would go away. >>> It didn't. >>> I find this to be an ugly and ad-hoc multiplexing of eventfd with added >>> functionalities of questionable general use. >>> I'm pretty sure you can do better on KVM side, to solve the problem w/out >>> littering eventfd. >> >> While we could argue about this my feeling is that we should drop this, at >> least until we can quantify what benefit it has and whether there are any >> Davide-acceptable alternatives. > > I really didn't mean to be harsh, but seriously, we cannot just have a > Multiplexing Feast over eventfd, with one-time users.
EFD_STATE actually does two changes: a) makes read block until the value changes; b) makes each write override the previous one. How would you feel if the two changes were separated? I can see each of them has use cases
For example, (a) could be implemented by using select's xfds (POLLPRI) to poll for value changes (rfds would still poll for non-zeroness). Then Michael does not need even to read the eventfd; instead he'd check POLLIN with a zero timeout.
(b) could be implemented with a flag like Michael did.
Paolo
| |