| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
- make kick_poller() do something on POSIX
- fix some conditions whereby alarms are held in a pollset exec context for too long
- make channel_connectivity tests dependent on the correct behavior
|
|/ |
|
|\
| |
| | |
Annotate blocking points
|
| |
| |
| |
| | |
core places besides iomgr
|
| |
| |
| |
| | |
for reasons other than synchronization
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|\ |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if two threads call grpc_completion_queue_pluck on the same
completion queue for different tags, there is a 50% chance that we
deliver the completion wakeup to the wrong poller - forcing the correct
poller to wait until its polling times out before it can return an event
up to the application.
This change tweaks our polling interfaces so that we can indeed wake a
specific poller.
Nothing has been performance tuned yet. It's definitely sub-optimal in a
number of places. Wakeup file-descriptors should be recycled. We should
have a path that avoids calling poll() followed by epoll(). We can
probably live without it right at the second though.
This code will fail on Windows at least (I'll do that port when I'm in the office and have a Windows
machine).
|
| |
|
| |
|
|
|
|
| |
orphaned by mistake
|
|
|
|
|
|
|
| |
Since alarm checks may mutate work deadlines for pollsets, the value
returned from maybe_work is meaningless. Instead, maybe pollset_work
always return 1 if maybe_work is invoked, and then redo the deadline
check _on the next call_ to pollset_work.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
Mostly to facilitate testing, but maybe in the future we want to work on
Linux systems with broken epoll support?
|
| |
| |
| |
| |
| | |
Allow multiple threads to be polling
Remove unnecessary windows stubs
|
|/ |
|
|
|
|
|
|
| |
- admit only one poller for read and one for write at a time
(poll is level triggered, so this avoids a thundering herd on each event)
- wake only one poller when more pollers are needed, again avoiding a thundering herd
|
| |
|
|
|
|
| |
it when notifying of an event
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a multipoller based on epoll rather than poll.
Note that this implementation is aimed at correctness rather than
performance, although it should immediately have better scalability to
large numbers of FDs, both due to epoll's O(1) sized API and due to not
needing to wake up polling threads to do interest set changes.
One notable difference here is that we directly attach a wakeup fd
rather than using the freelisting kick mechanism that the poll() based
implementations use, because modifying the epoll set to use a different
kick fd each time isn't free.
|
|
|
|
| |
Change the fd watcher from being O(active_pollers) to O(1), reducing time spent under the fd->watcher_mu lock, and ultimately scaling us much better.
|
| |
|
|
|
|
|
|
|
|
|
| |
This change pulls out a separate pollset_kick module, which currently
uses a freelist of pipes dynamically assigned to pollsets when they
enter polling rather than the previous racy sharding mechanism.
We ultimately may wish to eliminate the dynamic assignment for multipoll
sets, but this should be sufficient for the moment.
|
|
|
|
|
|
|
| |
Change on 2015/01/07 by ctiller <ctiller@google.com>
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83469190
|