date:20130724

[Qemu-devel] [PATCH] pc: limit 64 bit hole to 2G by default

2013-07-24 Thread Michael S. Tsirkin

It turns out that some 32 bit windows guests crash
if 64 bit PCI hole size is 2G.
Limit it to 2G for piix and q35 by default,
add properties to let management override the hole size.

Examples:
-global i440FX-pcihost.pci_hole64_size=137438953472

-global q35-pcihost.pci_hole64_size=137438953472

Reported-by: Igor Mammedov imamm...@redhat.com,
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
 hw/i386/pc.c  | 35 ---
 hw/i386/pc_piix.c | 14 +-
 hw/pci-host/piix.c| 42 ++
 hw/pci-host/q35.c | 29 +
 include/hw/i386/pc.h  |  7 +--
 include/hw/pci-host/q35.h |  1 +
 6 files changed, 78 insertions(+), 50 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a7c578f..9cc0fda 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1072,27 +1072,32 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t 
below_4g_mem_size,
 memset(guest_info-found_cpus, 0, sizeof guest_info-found_cpus);
 qemu_for_each_cpu(pc_set_cpu_guest_info, guest_info);
 
-guest_info-pci_info.w32.end = IO_APIC_DEFAULT_ADDRESS;
-if (sizeof(hwaddr) == 4) {
-guest_info-pci_info.w64.begin = 0;
-guest_info-pci_info.w64.end = 0;
-} else {
+guest_info_state-machine_done.notify = pc_guest_info_machine_done;
+qemu_add_machine_init_done_notifier(guest_info_state-machine_done);
+return guest_info;
+}
+
+void pc_init_pci_info(PcPciInfo *pci_info,
+  uint64_t pci_hole64_start,
+  uint64_t pci_hole64_size)
+{
+pci_info-w32.end = IO_APIC_DEFAULT_ADDRESS;
+
+if (pci_hole64_size  ((0x1  30) - 1)) {
+error_report(Invalid value for pci_hole64_size: 
+ must be a multiple of 1G. Rounding up.);
+}
+pci_hole64_size = ROUND_UP(pci_hole64_size, 0x1ULL  30);
+
 /*
  * BIOS does not set MTRR entries for the 64 bit window, so no need to
  * align address to power of two.  Align address at 1G, this makes sure
  * it can be exactly covered with a PAT entry even when using huge
  * pages.
  */
-guest_info-pci_info.w64.begin =
-ROUND_UP((0x1ULL  32) + above_4g_mem_size, 0x1ULL  30);
-guest_info-pci_info.w64.end = guest_info-pci_info.w64.begin +
-(0x1ULL  31);
-assert(guest_info-pci_info.w64.begin = guest_info-pci_info.w64.end);
-}
-
-guest_info_state-machine_done.notify = pc_guest_info_machine_done;
-qemu_add_machine_init_done_notifier(guest_info_state-machine_done);
-return guest_info;
+pci_info-w64.begin = ROUND_UP(pci_hole64_start, 0x1ULL  30);
+pci_info-w64.end = pci_info-w64.begin + pci_hole64_size;
+assert(pci_info-w64.begin = pci_info-w64.end);
 }
 
 void pc_acpi_init(const char *default_dsdt)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 76df42b..da61fa3 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -137,15 +137,6 @@ static void pc_init1(MemoryRegion *system_memory,
 
 guest_info-has_pci_info = has_pci_info;
 
-/* Set PCI window size the way seabios has always done it. */
-/* Power of 2 so bios can cover it with a single MTRR */
-if (ram_size = 0x8000)
-guest_info-pci_info.w32.begin = 0x8000;
-else if (ram_size = 0xc000)
-guest_info-pci_info.w32.begin = 0xc000;
-else
-guest_info-pci_info.w32.begin = 0xe000;
-
 /* allocate ram and load rom/bios */
 if (!xen_enabled()) {
 fw_cfg = pc_memory_init(system_memory,
@@ -169,10 +160,7 @@ static void pc_init1(MemoryRegion *system_memory,
   below_4g_mem_size,
   0x1ULL - below_4g_mem_size,
   0x1ULL + above_4g_mem_size,
-  (sizeof(hwaddr) == 4
-   ? 0
-   : ((uint64_t)1  62)),
-  pci_memory, ram_memory);
+  pci_memory, ram_memory, guest_info);
 } else {
 pci_bus = NULL;
 i440fx_state = NULL;
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 7fb2fb1..963b3d8 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -40,6 +41,7 @@
 
 typedef struct I440FXState {
 PCIHostState parent_obj;
+uint64_t pci_hole64_size;
 } I440FXState;
 
 #define PIIX_NUM_PIC_IRQS   16  /* i8259 * 2 */
@@ -234,9 +236,9 @@ static PCIBus *i440fx_common_init(const char *device_name,
   hwaddr pci_hole_start,
   hwaddr pci_hole_size,
   hwaddr pci_hole64_start,
-  hwaddr pci_hole64_size,
   MemoryRegion *pci_address_space,
-  MemoryRegion

Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff

2013-07-24 Thread Paolo Bonzini

Il 24/07/2013 03:28, liu ping fan ha scritto:
 On Tue, Jul 23, 2013 at 6:30 PM, Paolo Bonzini pbonz...@redhat.com wrote:
  Il 23/07/2013 04:53, liu ping fan ha scritto:
  The scenior I can figure out is if adopting timeout of poll, then when
  changing the deadline, we need to invoke poll, and set the new
  timeout, right?
 
  Yes, you need to call aio_notify so that poll is reinvoked.
 
 I try to list the difference between alarm_timer and timeout of poll.
 It includes thread-affinity, resolution and easy-use.
 
 Most of all,  thread-affinity
 The main issue with alarm timer is the affinity of timer_t with
 threads. For linux, SIGEV_THREAD_ID has been supported for a very long
 time and we already associate the signal with the specified thread. So
 the only issue is left for other unix, we can emulate the affinity by
 using SIGEV_THREAD and repost the event to the specified thread.
 As to timeout of poll, it has the affinity of threads.
 
 Resolution:
 alarm_timer provides higher resolution, but do we care about it?

With ppoll, is this true or just hearsay?

(Without ppoll, indeed setitimer has 1 us resolution while poll has 1
ms; too bad that select has other problems, because select has also 1 us
resolution).

Paolo

 easy-use:
 The reset of the deadline as mentioned.
 
 Finally, I admit timeout of poll will save large chunk of platform-related 
 code.

Re: [Qemu-devel] trim in windows guest witch virtio

2013-07-24 Thread Paolo Bonzini

Il 24/07/2013 02:53, Libaiqing ha scritto:
 Hi paolo,
 
 I test window guest with ide device with the following config,trim with 
 ide drive failed.
 
  1 The host fs is ext4 with discard option: 
/dev/sdb1 on /home/sdb type ext4 (rw,relatime,discard,data=ordered)
  
  2 qemu config : ide drive with discard open
 x86_64-softmmu/qemu-system-x86_64 -enable-kvm -name win7 -M pc-0.15 -m 1024 
 -smp 2 -boot c -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2  -drive 
 file=/home/win7_base.qcow2,if=ide,index=0,format=qcow2,id=ad  -drive 
 file=/home/sdb/raw.img,if=ide,index=1,format=raw,id=hd,discard=on  -monitor 
 stdio   -vga qxl  -vnc :1 -device usb-tablet,id=input0

TRIM is supported only on -M pc-1.5 and -M pc.

  3 In win7 guest,init drive d,fill it with files,then shift+del files
 
  4 The file /home/sdb/raw.img does not become small,when listing with -s 
 option.
 
  It seems that the windows ntfs does not send trim to ide controller. No 
 IDE_DMA_TRIM request received.

Note that this may not happen immediately.  NTFS may send TRIM later.

  Is there any config wrong?
 
  Btw,I found the info from the URL: 
 http://msdn.microsoft.com/en-us/library/windows/desktop/hh848053(v=vs.85).aspx
  Qemu can do the same thing like hyper-v with windows guest?

I don't know, I never tested it with Windows guests.  It looks like
Windows 8 would not need a filter driver to do TRIM on SCSI disks (you
could try with megasas, so that you do not need a driver for the HBA).

Paolo

Re: [Qemu-devel] [PATCH] pc: limit 64 bit hole to 2G by default

2013-07-24 Thread Andreas Färber

Hi,

Am 24.07.2013 08:01, schrieb Michael S. Tsirkin:
 It turns out that some 32 bit windows guests crash
 if 64 bit PCI hole size is 2G.
 Limit it to 2G for piix and q35 by default,
 add properties to let management override the hole size.
 
 Examples:
 -global i440FX-pcihost.pci_hole64_size=137438953472
 
 -global q35-pcihost.pci_hole64_size=137438953472
 
 Reported-by: Igor Mammedov imamm...@redhat.com,
 Signed-off-by: Michael S. Tsirkin m...@redhat.com
 ---
  hw/i386/pc.c  | 35 ---
  hw/i386/pc_piix.c | 14 +-
  hw/pci-host/piix.c| 42 ++
  hw/pci-host/q35.c | 29 +
  include/hw/i386/pc.h  |  7 +--
  include/hw/pci-host/q35.h |  1 +
  6 files changed, 78 insertions(+), 50 deletions(-)
[...]
 diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
 index 7fb2fb1..963b3d8 100644
 --- a/hw/pci-host/piix.c
 +++ b/hw/pci-host/piix.c
 @@ -40,6 +41,7 @@
  
  typedef struct I440FXState {
  PCIHostState parent_obj;
 +uint64_t pci_hole64_size;
  } I440FXState;
  
  #define PIIX_NUM_PIC_IRQS   16  /* i8259 * 2 */
 @@ -234,9 +236,9 @@ static PCIBus *i440fx_common_init(const char *device_name,
hwaddr pci_hole_start,
hwaddr pci_hole_size,
hwaddr pci_hole64_start,
 -  hwaddr pci_hole64_size,
MemoryRegion *pci_address_space,
 -  MemoryRegion *ram_memory)
 +  MemoryRegion *ram_memory,
 +  PcGuestInfo *guest_info)
  {
  DeviceState *dev;
  PCIBus *b;
 @@ -245,15 +247,31 @@ static PCIBus *i440fx_common_init(const char 
 *device_name,
  PIIX3State *piix3;
  PCII440FXState *f;
  unsigned i;
 +I440FXState *i440fx;
  
  dev = qdev_create(NULL, i440FX-pcihost);
  s = PCI_HOST_BRIDGE(dev);
 +i440fx = OBJECT_CHECK(I440FXState, dev, i440FX-pcihost);

If we're lacking a macro for this, please define one. E.g.:
#define TYPE_I440FX i440FX-pcihost
#define I440FX(obj) OBJECT_CHECK(I440FXState, (obj), TYPE_I440FX)
above I440FXState.

i440fx = I440FX(dev);

So far was unused due to PCI_HOST_BRIDGE(), I guess.

  b = pci_bus_new(dev, NULL, pci_address_space,
  address_space_io, 0, TYPE_PCI_BUS);
  s-bus = b;
  object_property_add_child(qdev_get_machine(), i440fx, OBJECT(dev), 
 NULL);
  qdev_init_nofail(dev);
  
 +if (guest_info) {
 +/* Set PCI window size the way seabios has always done it. */
 +/* Power of 2 so bios can cover it with a single MTRR */
 +if (ram_size = 0x8000)
 +guest_info-pci_info.w32.begin = 0x8000;
 +else if (ram_size = 0xc000)
 +guest_info-pci_info.w32.begin = 0xc000;
 +else
 +guest_info-pci_info.w32.begin = 0xe000;
 +
 +pc_init_pci_info(guest_info-pci_info,
 + pci_hole64_start, i440fx-pci_hole64_size);
 +}
 +
  d = pci_create_simple(b, 0, device_name);
  *pi440fx_state = I440FX_PCI_DEVICE(d);
  f = *pi440fx_state;
 @@ -265,8 +283,8 @@ static PCIBus *i440fx_common_init(const char *device_name,
  memory_region_add_subregion(f-system_memory, pci_hole_start, 
 f-pci_hole);
  memory_region_init_alias(f-pci_hole_64bit, OBJECT(d), pci-hole64,
   f-pci_address_space,
 - pci_hole64_start, pci_hole64_size);
 -if (pci_hole64_size) {
 + pci_hole64_start, i440fx-pci_hole64_size);
 +if (i440fx-pci_hole64_size) {
  memory_region_add_subregion(f-system_memory, pci_hole64_start,
  f-pci_hole_64bit);
  }
 @@ -322,8 +340,8 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int 
 *piix3_devfn,
  hwaddr pci_hole_start,
  hwaddr pci_hole_size,
  hwaddr pci_hole64_start,
 -hwaddr pci_hole64_size,
 -MemoryRegion *pci_memory, MemoryRegion *ram_memory)
 +MemoryRegion *pci_memory, MemoryRegion *ram_memory,
 +PcGuestInfo *guest_info)
  
  {
  PCIBus *b;
 @@ -332,8 +350,9 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int 
 *piix3_devfn,
 piix3_devfn, isa_bus, pic,
 address_space_mem, address_space_io, ram_size,
 pci_hole_start, pci_hole_size,
 -   pci_hole64_start, pci_hole64_size,
 -   pci_memory, ram_memory);
 +   pci_hole64_start,
 +   pci_memory, ram_memory,
 +   guest_info);
  return b;

Re: [Qemu-devel] [PATCH] pc: limit 64 bit hole to 2G by default

2013-07-24 Thread Gerd Hoffmann

On 07/24/13 08:01, Michael S. Tsirkin wrote:
 It turns out that some 32 bit windows guests crash
 if 64 bit PCI hole size is 2G.

Ah, *that* is the reason for winxp crashing with a 64bit hole.

Current seabios uses a slightly different approach: the 64bit hole is
present only in case it is actually used to map bars there, and seabios
tries to fit everything into the 32bit hole first.

 Limit it to 2G for piix and q35 by default,
 add properties to let management override the hole size.
 
 Examples:
 -global i440FX-pcihost.pci_hole64_size=137438953472

Do we really want specify this in bytes?  Using megabytes or gigabytes
instead looks more sane to me.

cheers,
  Gerd

[Qemu-devel] [RFC] [PATCH] linux-user: implement m68k atomic syscalls

2013-07-24 Thread riku . voipio

From: Riku Voipio riku.voi...@linaro.org

With nptl enabled, atomic_cmpxchg_32 and atomic_barrier
system calls are needed. This patch enabled really dummy
versions of the system calls, modeled after the m68k
kernel code.

With this patch I am able to execute m68k binaries
with qemu linux-user (busybox compiled for coldfire).

Cc: Laurent Vivier laur...@vivier.eu
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
 linux-user/strace.list |  6 ++
 linux-user/syscall.c   | 20 
 2 files changed, 26 insertions(+)

diff --git a/linux-user/strace.list b/linux-user/strace.list
index 08f115d..4377365 100644
--- a/linux-user/strace.list
+++ b/linux-user/strace.list
@@ -1524,3 +1524,9 @@
 #ifdef TARGET_NR_pipe2
 { TARGET_NR_pipe2, pipe2, NULL, NULL, NULL },
 #endif
+#ifdef TARGET_NR_atomic_cmpxchg_32
+{ TARGET_NR_atomic_cmpxchg_32, atomic_cmpxchg_32, NULL, NULL, NULL },
+#endif
+#ifdef TARGET_NR_atomic_barrier
+{ TARGET_NR_atomic_barrier, atomic_barrier, NULL, NULL, NULL },
+#endif
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 3f6db4b..a98cec5 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -8990,6 +8990,26 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 break;
 }
 #endif
+#ifdef TARGET_NR_atomic_cmpxchg_32
+case TARGET_NR_atomic_cmpxchg_32:
+{
+/* should use start_exclusive from main.c */
+abi_ulong mem_value;
+if (get_user_u32(mem_value, arg6))
+ret = -TARGET_EFAULT;
+if (mem_value == arg2)
+put_user_u32(arg1, arg6);
+ret = mem_value;
+break;
+}
+#endif
+#ifdef TARGET_NR_atomic_barrier
+case TARGET_NR_atomic_barrier:
+{
+/* Like the kernel implementation and the qemu arm barrier, no-op 
this? */
+break;
+}
+#endif
 default:
 unimplemented:
 gemu_log(qemu: Unsupported syscall: %d\n, num);
-- 
1.8.1.2

Re: [Qemu-devel] [sheepdog] [PATCH 00/11] sheepdog: reconnect server after connection failure

2013-07-24 Thread MORITA Kazutaka

At Tue, 23 Jul 2013 13:08:04 +0200,
Luca Lazzeroni wrote:
 
 Is this series of patches applyable to sheepdog-stable-0.6 band qemu 1.5.0 ? 
 I've seen they use  async i/o...

This series is against upstream qemu.  I've not tried it with qemu
1.5.x, but probably it can be applied without a big change.

Thanks,

Kazutaka

Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff

2013-07-24 Thread Alex Bligh




--On 24 July 2013 08:42:26 +0200 Paolo Bonzini pbonz...@redhat.com wrote:


With ppoll, is this true or just hearsay?

(Without ppoll, indeed setitimer has 1 us resolution while poll has 1
ms; too bad that select has other problems, because select has also 1 us
resolution).


Most 'reasonable' POSIX compliant operating systems have ppoll and I would
have thought there is /better/ resolution there than relying not only
on signal, but also a pipe or eventfd plus the underlying poll().

If it was my comments you are referring to, my concern was mainly about
Windows (which I know very little about), as there does not appear
to be a nanosecond or even microsecond alternative to
WaitForMultipleObjects. However, articles like this:


http://social.msdn.microsoft.com/Forums/vstudio/en-US/e8a7cb1e-9edd-4ee3-982e-f66b7bf6ae44/improve-accuracy-waitforsingleobject

suggest that WaitFor{Single,Multiple}Objects can have pretty
appalling latency anyway (100ms!), and there's no evidence that's
limited by making one of the FDs (or objects) ready. In these
circumstances, I'd question whether we gain anything by worrying
about timer resolution.

--
Alex Bligh

Re: [Qemu-devel] [PATCH v2 01/11] block: replace in_use with refcnt_soft and refcnt_hard

2013-07-24 Thread Stefan Hajnoczi

On Wed, Jul 24, 2013 at 08:39:53AM +0800, Fam Zheng wrote:
 On Tue, 07/23 15:34, Stefan Hajnoczi wrote:
  On Tue, Jul 23, 2013 at 06:32:25PM +0800, Fam Zheng wrote:
   On Tue, 07/23 11:36, Stefan Hajnoczi wrote:
On Wed, Jul 17, 2013 at 05:42:06PM +0800, Fam Zheng wrote:
 Introduce refcnt_soft (soft reference) and refcnt_hard (hard 
 reference)
 to BlockDriverState, since in_use mechanism cannot provide proper
 management of lifecycle when a BDS is referenced in multiple places
 (e.g. pointed to by another bs's backing_hd while also used as a block
 job device, in the use case of image fleecing).
 
 The original in_use case is considered a hard reference in this 
 patch,
 where the bs is busy and should not be used in other tasks that 
 require
 a hard reference. (However the interface doesn't force this, caller
 still need to call bdrv_in_use() to check by itself.).
 
 A soft reference is implemented but not used yet. It will be used in
 following patches to manage the lifecycle together with hard 
 reference.
 
 If bdrv_ref() is called on a BDS, it must be released by exactly the
 same numbers of bdrv_unref() with the same soft/hard type, and never
 call bdrv_delete() directly. If the BDS is only used locally 
 (unnamed),
 bdrv_ref/bdrv_unref can be skipped and just use bdrv_delete().

It is risky to keep bdrv_delete() public.  I suggest replacing
bdrv_delete() callers with bdrv_unref() and then making bdrv_delete()
static in block.c.

This way it is impossible to make the mistake of calling bdrv_delete()
on a BDS which has refcnt  1.

I don't really understand this patch.  There are now two separate
refcounts.  They must both reach 0 for deletion to occur.  I think
you plan to treat the hard refcount like the in_use counter (there
should only be 0 or 1 refs) but you don't enforce it.  It seems cleaner
to keep in_use separate: let in_use callers take a refcount and also set
in_use.
   
   OK, I like your ideas, make bdrv_delete private is much cleaner. Will
   fix in next revision.
   
   I plan to make it like this:
   
   /* soft ref */
   void bdrv_{ref,unref}(bs)
   
   /* hard ref */
   bool bdrv_hard_{ref,unref}(bs)
   
   usage:
   bs = bdrv_new()
   implicit bdrv_ref(bs) called
   ...
   bdrv_unref(bs)
   automatically deleted here
   
   or with hard ref:
   bs = bdrv_new()
   implicit bdrv_ref() called
   
   bdrv_hard_ref(bs)
   ...
   bdrv_hard_unref(bs)
   
   bdrv_unref(bs)
   automatically deleted here
   
   The second bdrv_hard_ref call to a bs returns false, caller check the
   return value.
  
  Why is hard ref necessary when we already have
  bdrv_in_use()/bdrv_set_in_use()?
 
 Keeping the names of bdrv_in_use() and bdrv_set_in_use() is noting
 wrong, if no more than one hard ref is enforced. However I think we
 should manage lifecycle with both bdrv_ref and bdrv_set_in_use, so name
 them both ref sounds consistent: make it clearer to caller both hard ref
 (in_use) and soft ref preserve the bs from being released.

I actually find hard/soft ref naming confusing and prefer keeping
bdrv_in_use().  Refcount is for object lifetime whereas in_use is for
busy status.

Stefan

Re: [Qemu-devel] [sheepdog] [PATCH 03/11] qemu-sockets: make wait_for_connect be invoked in qemu_aio_wait

2013-07-24 Thread MORITA Kazutaka

At Tue, 23 Jul 2013 13:36:08 +0200,
Paolo Bonzini wrote:
 
 Il 23/07/2013 10:30, MORITA Kazutaka ha scritto:
  This allows us to use inet_nonblocking_connect() and
  unix_nonblocking_connect() in block drivers.
  
  qemu-ga needs to link block-obj to resolve dependencies of
  qemu_aio_set_fd_handler().
  
  Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
 
 I'm not sure this is safe.  You could have e.g. migration start during
 qemu_aio_wait().

I thought that it is safe.  Qemu creates another thread for migration
and it can be started at any time, either way.  However, so as not to
hurt the existing codes, it might be better to create another
nonblocking connect for qemu_aio_wait().

I think of dropping this patch from this series and will leave it for
another day.  Usually, sheepdog users prepare a local sheepdog daemon
to be connected to, and connect() is unlikely to sleep for a long
time.  Using a blocking connect wouldn't be a big problem.

Thanks,

Kazutaka

Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff

2013-07-24 Thread Paolo Bonzini

Il 24/07/2013 09:31, Alex Bligh ha scritto:

--On 24 July 2013 08:42:26 +0200 Paolo Bonzini pbonz...@redhat.com wrote:

With ppoll, is this true or just hearsay?

(Without ppoll, indeed setitimer has 1 us resolution while poll has 1
ms; too bad that select has other problems, because select has also 1 us
resolution).

Most 'reasonable' POSIX compliant operating systems have ppoll

Really? I could find no manpages for any of Solaris and *BSD.

and I would
have thought there is /better/ resolution there than relying not only
on signal, but also a pipe or eventfd plus the underlying poll().

I agree.

If it was my comments you are referring to

The message I replied to was Ping Fan's, but perhaps you brought it up
first. I don't know.

, my concern was mainly about
Windows (which I know very little about), as there does not appear
to be a nanosecond or even microsecond alternative to
WaitForMultipleObjects. However, articles like this:

http://social.msdn.microsoft.com/Forums/vstudio/en-US/e8a7cb1e-9edd-4ee3-982e-f66b7bf6ae44/improve-accuracy-waitforsingleobject

suggest that WaitFor{Single,Multiple}Objects can have pretty
appalling latency anyway (100ms!), and there's no evidence that's
limited by making one of the FDs (or objects) ready.

1 2 3 >

1 - 100 of 243 matches

Mail list logo