| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
I *believe* this is actually safe, and the assert was errantly
copy-pasted a while back.
Fixes #3022
|
|\ |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
|
|
|
|
| |
close() could race with epoll_ctl(); pretend to be polling while adding
to the epoll set to prevent this
|
|
|
|
|
|
|
| |
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?
|
|/ |
|
|
|
|
| |
in epoll wait.
|
| |
|
| |
|
|
|
|
|
|
|
| |
1. Close the epoll_fd at destroy
2. Finish the comment about signal/broadcast on the cv
3. Rename GPR_POSIX_MULTIPOLL_WITH_EPOLL to
GPR_LINUX_MULTIPOLL_WITH_EPOLL
|
| |
|
|
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.
|