3 ms·

NT's approach to async IO is at least somewhat empirically better as it does not require an extra context switch between receiving a "ready" event and actually

• deprave 10y ago
  You must mean "theoretically" because "empirically" implies that you're basing your statement on observations. Where are the numbers? :)
• gpderetta 10y ago
  Completion notification requires committing a (potentially cache-hot) buffer for an operation that might not complete until some time in the future. With readiness notification you only need to have the buffer ready when you know you will use it. Also, on an high performance poll/epoll/kevent based system you only need to poll cold fds, while you can do speculative direct read/writes to hot fds, so no need for extra syscalls in the fast case. That doesn't mean that completion notification doesn't have its advantages, especially when coupled with NT builtin auto-sizing thread pool, but it is not strictly better.
  • trentnelson 10y ago
    You could do that if you really wanted on Windows; just set a 0 byte user space send and receive socket buffer. You can do dual synchronous/asynchronous socket I/O in Windows. I use this very approach with PyParallel (and 0 byte send buffers): https://github.com/pyparallel/pyparallel/blob/branches/3.3-px/Python/pyparallel.c#L9471 https://github.com/pyparallel/pyparallel/blob/branches/3.3-p... Depending on current load, that will either immediately do an asynchronous operation, or attempt synchronous non-blocking ones up to a certain number, then fall back to asynchronous. Described here: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=120 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...