Questions about the polling engine inside the core.

115 views
Skip to first unread message

Arthur Wang

unread,
Apr 16, 2019, 5:55:43 AM4/16/19
to grp...@googlegroups.com
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.  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!


Nicolas Noble

unread,
Apr 16, 2019, 8:16:18 PM4/16/19
to Arthur Wang, grpc.io
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.

--
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 grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages