* [Qemu-devel] qemu_cond_wait polling
@ 2009-07-28 7:16 Jan Kiszka
2009-07-28 9:18 ` [Qemu-devel] " Avi Kivity
0 siblings, 1 reply; 2+ messages in thread
From: Jan Kiszka @ 2009-07-28 7:16 UTC (permalink / raw)
To: qemu-devel, kvm-devel
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
Hi,
why do we wait on condition variables with silly timeouts (both in
upstream as in qemu-kvm)? There used to be some qemu_aio_poll in
qemu-kvm, but it's no longer there, and upstream never had (unless I
missed something). Is this polling legacy now? Remove it?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Qemu-devel] Re: qemu_cond_wait polling
2009-07-28 7:16 [Qemu-devel] qemu_cond_wait polling Jan Kiszka
@ 2009-07-28 9:18 ` Avi Kivity
0 siblings, 0 replies; 2+ messages in thread
From: Avi Kivity @ 2009-07-28 9:18 UTC (permalink / raw)
To: Jan Kiszka; +Cc: qemu-devel, kvm-devel
On 07/28/2009 10:16 AM, Jan Kiszka wrote:
> Hi,
>
> why do we wait on condition variables with silly timeouts (both in
> upstream as in qemu-kvm)? There used to be some qemu_aio_poll in
> qemu-kvm, but it's no longer there, and upstream never had (unless I
> missed something). Is this polling legacy now? Remove it?
>
>
Given that all uses are inside while loops, the timeouts are ignored.
It's completely pointless now.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-07-28 9:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-28 7:16 [Qemu-devel] qemu_cond_wait polling Jan Kiszka
2009-07-28 9:18 ` [Qemu-devel] " Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).