| Commit message (Collapse) | Author | Age |
|\
| |
| | |
Ensure there is no concurrent poller for unary->multipoll
|
| |
| |
| |
| |
| |
| | |
Instead, we do a shutdown() at the point we are currently closing, to
kick off socket teardown while ensuring an fd ref is sufficient to make
concurrent syscalls like epoll_ctl safe.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\
| |/
|/| |
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
|/ / |
|
| |
| |
| |
| | |
This will help greatly when it comes to diagnosing customer issues.
|
|\ \
| | |
| | | |
Fix TSAN reported error in fd_posix.c
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The race here is:
Initially unary poller has one FD, FD_1
Thread 1 adds FD_2, promoting to multipoll, entailing epoll_ctl on FD_1
and FD_2.
Concurrently, Thread 2 returns from unary poll and executes one of
FD_1's callbacks, which ultimately leads to a close(FD_1) which races
with the epoll_ctl by thread 1.
The solution is to ensure that we don't concurrently poll and promote,
which requires a bit of extra care.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now pass down pointers to closures instead of (callback, arg) pair
elements separately. This allows us to store one word atomically, fixing
a race condition.
All call sites have been updated to the new API. No new allocations are
incurred. grpc_fd_state is deleted to avoid any temptation to ever add
anything there again.
|
|/
|
|
| |
in epoll wait.
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Remove existing UDS listeners IFF they are a socket before trying to create a new socket.
|
| |
| |
| |
| |
| | |
This prevents a bug whereby not all fds were destroyed at application
exit.
|
| | |
|
|\| |
|
| | |
|
|\|
| |
| |
| |
| | |
Conflicts:
Makefile
|
|\ \ |
|
| | |\
| | |/
| |/| |
|
| | | |
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| | |
-) Let's not use _POSIX_SOURCE. It usually implies too much C99. _BSD_SOURCE would be the right thing to do here.
-) _BSD_SOURCE is getting deprecated by glibc, so we also have to define _DEFAULT_SOURCE under Linux.
-) accept4 and eventfd arn't as old as we may think; let's detect for it.
-) stdint.h interferes with all these definitions if included too early; let's move it down.
|
|/
|
|
|
|
| |
Allow binding a different completion queue to each registered method.
This will allow multiplexing for the C++ server between sync & async
methods more easily.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|\ |
|
| |\
| | |
| | | |
Windows port of iomgr.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|/ /
| |
| |
| |
| |
| |
| | |
This avoids an unnecessary upgrade to multipoller if there was no
do_work called between an orphan and a subsequent add. Additionally, it
avoids the need for epoll based multipoller to check for this case in
its upgrade code by ensuring all existing fds are valid at upgrade time.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |/
|/|
| |
| | |
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 was an observed source of contention at higher thread counts where
we could overrun the freelist cap.
|
| | |
|
| |
| |
| |
| | |
There's no need for this branch at all.
|
| |
| |
| |
| | |
Theres no need for every thread to exit polling early if an alarm might finish, so there's no need to contend here.
|
|\ \
| | |
| | | |
Fix up feature test macros
|