- Jun 23, 2015
-
-
Nicolas Noble authored
With the backup poller gone, the caller of grpc_pollset_work is expecting it to sleep. Aligning the behavior of the Windows port with the behavior of the Posix port.
-
- Jun 18, 2015
-
-
Craig Tiller authored
-
- Jun 05, 2015
-
-
Craig Tiller authored
-
- May 07, 2015
-
-
Craig Tiller authored
-
- Mar 01, 2015
-
-
Nicolas "Pixel" Noble authored
-
- Feb 24, 2015
-
-
David Klempner authored
This allows us to safely asynchronously add FDs in the possibly-promoting unary add case. Also fix the unary add async path to properly handle more of the extra cases it needs to handle.
-
- Feb 18, 2015
-
-
Craig Tiller authored
-
Craig Tiller authored
-
- Jan 22, 2015
-
-
Craig Tiller authored
They're not needed on Windows
-
- Jan 10, 2015
-
-
ctiller authored
Fixed any exposed bugs across the stack. Add a poll() based implementation. Heavily leverages pollset infrastructure to allow small polls to be the norm. Exposes a mechanism to plug in epoll/kqueue for platforms where we have them. Simplify iomgr callbacks to return one bit of success or failure (instead of the multi valued result that was mostly unused previously). This will ease the burden on new implementations, and the previous system provided no real value anyway. Removed timeouts on endpoint read/write routines. This simplifies porting burden by providing a more orthogonal interface, and the functionality can always be replicated when desired by using an alarm combined with endpoint_shutdown. I'm fairly certain we ended up with this interface because it was convenient to do from libevent. Things that need attention still: - adding an fd to a pollset is O(n^2) - but this is probably ok given that we'll not use this for multipolling once platform specific implementations are added. - we rely on the backup poller too often - especially for SSL handshakes and for client connection establishment we should have a better mechanism ([] [] - Linux needs to use epoll for multiple fds, FreeBSD variants (including Darwin) need to use kqueue. ([] [] - Linux needs to use eventfd for poll kicking. ([] Change on 2015/01/07 by ctiller <ctiller@google.com> ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=83461069
-
ctiller authored
Change on 2015/01/07 by ctiller <ctiller@google.com> ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=83451760
-
- Jan 09, 2015
-
-
Craig Tiller authored
-
- Jan 08, 2015
-
-
ctiller authored
Fixed any exposed bugs across the stack. Add a poll() based implementation. Heavily leverages pollset infrastructure to allow small polls to be the norm. Exposes a mechanism to plug in epoll/kqueue for platforms where we have them. Simplify iomgr callbacks to return one bit of success or failure (instead of the multi valued result that was mostly unused previously). This will ease the burden on new implementations, and the previous system provided no real value anyway. Removed timeouts on endpoint read/write routines. This simplifies porting burden by providing a more orthogonal interface, and the functionality can always be replicated when desired by using an alarm combined with endpoint_shutdown. I'm fairly certain we ended up with this interface because it was convenient to do from libevent. Things that need attention still: - adding an fd to a pollset is O(n^2) - but this is probably ok given that we'll not use this for multipolling once platform specific implementations are added. - we rely on the backup poller too often - especially for SSL handshakes and for client connection establishment we should have a better mechanism ([] [] - Linux needs to use epoll for multiple fds, FreeBSD variants (including Darwin) need to use kqueue. ([] [] - Linux needs to use eventfd for poll kicking. ([] Change on 2015/01/07 by ctiller <ctiller@google.com> ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=83461069
-
- Dec 19, 2014
-
-
ctiller authored
This CL introduces the public side of this interface. There will need to be an iomgr-private API also, but this will be a per-implementation API and so is not covered here. I've taken care of wiring the interface through the codebase in the manner that I expect it will be used. Change on 2014/12/17 by ctiller <ctiller@google.com> ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=82376987
-
- Nov 27, 2014
-
-
Nicolas Noble authored
-