On 02/22/2010 05:42 PM, Anthony Liguori wrote:
Spurious calls to qemu_notify_event() also make it difficult to tell
when it's actually necessary to call qemu_notify_event() vs. when
it's just something that doesn't hurt.
One improvement in this area would be to add a context parameter
(which eventually resolves to the underlying thread). Currently we'd
ignore it since we have just one iothread, but it would serve to
document what's being polled, and later direct the wakeup to the
correct thread.
Ends up looking a lot like a condition. It's not necessarily a bad
thing to model.
But the implementation is very different - condition variables sleep in
pthread_cond_wait, the iothread sleeps in poll().
qemu_notify_event() is really requesting iothread t to re-add file fd to
its poll set. Maybe we should make this a CharDriverState method.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
