Hi all :
1. How could the "Thundering Herds" phenomenon happened ?
I know if we use epoll with ET properly , actually only one thread will awoke from epoll_wait even multiple thread are blocking on it at the moment when some fds are ready, consulting from the
epoll man page. Whereas I don't find poll has such capabilities .
So the reason for "Thundering Herds" is just because the core using poll rather than epoll ?
- If the answer is Yes, why using poll then ? For the compatibility on *nix platforms ?
- If the answer is No, what's the true reason?
2. For this paragraph :
For example, in Figure 1, if fd1 becomes readable, any one of the threads i.e Threads 1 to Threads K or Thread P, might be woken up. Let's say Thread P was calling a grpc_completion_queue_pluck() and was actually interested in the event on fd1 but Thread 1 woke up. In this case, Thread 1 executes the callbacks and finally kicks Thread P by signalling event_fd_P. Thread P wakes up, realizes that there is a new completion event for it and returns from grpc_completion_queue_pluck() to its caller.
1> what's the meaning of "actually interested in the event"?
For my understanding , all the threads which are calling 'grpc_completion_queue_pluck' or 'grpc_completion_queue_next' are symmetric , they are all the threads from the upper application layer, and they will
do the corresponding work related to the event it got , share nothing difference. Why one could distinguishing from the other by "interested in the event or not"?
2> Regardless of question 1>.
If "Thread 1 finishes executing the callbacks" , why it still have to "kicks Thread P by signalling event_fd_P",hasn't the task been finished due to Thread 1's execution? Why thread 1 need to kick thread P ?
I'm lack of the knowledge of the interaction details between completionQueue and epoll_set , so the above questions may seems silly, I'm very appreciated for patient answers. Thanks!