You need to understand the fact that http2 is a single stream that can contain a lot of streams. It's not going to be a single file descriptor per rpc, but rather, you are going to potentially have a lot of in-flight rpc on a single http2 connection. Therefore you may have lots of threads waiting for events on a single file descriptor. In this design, poll isn't used to wait for sockets events. It's used to wait for events happening on the epoll fds themselves.
On Tue, Apr 16, 2019 at 2:55 AM Arthur Wang <[email protected]> wrote: > Hi all : > I'm learning the polling engine of grpc core by reading this doc : > https://github.com/grpc/grpc/blob/master/doc/core/epoll-polling-engine.md. > I have some questions: > > 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 > <http://man7.org/linux/man-pages/man7/epoll.7.html>. 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! > > -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/CAKymdqPuOpH-C2TgBbO9DPuOchDTQ%2BN_NAO-qDgoAc9Qh4W4ZA%40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CAKymdqPuOpH-C2TgBbO9DPuOchDTQ%2BN_NAO-qDgoAc9Qh4W4ZA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAEvr0PH8%3DUZFvGB8DzD4c6QcdM7CCUxJFzWLDOCpfVTuWw2WhQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
