As mentioned above, requests are received through multiplexing I/O in ril_event_loop, and Initialization is also analyzed. Now let's take a closer look at how this mechanism works. Ril_event_set is responsible for configuring an event. There are two main types of events: Ril_event_add adds an event that uses multi-path I/O. It is responsible for attaching the event to the queue, adding the event channel handle FD to watch_table, and then waiting through select. Ril_timer_add adds a timer event, which is attached to the queue and recalculates the shortest timeout time. Whatever the add method, triggerevloop will be called to refresh the queue, update the timeout value or wait for the object. After the refresh, ril_event_loop returns the result from the blocking position and select. There are only two possibilities: timeout and I/O. Timeout processing in processtimeouts, remove the timeout event and add pending_list. Check the processing of channels with I/O operations in processreadreadies and add the time-out event to pending_list. Finally, in firepending, retrieve the pending_list event and execute the event-> func. After these operations are completed, calculate the new timeout time and re-select to block Multiple I/O. The previous initialization process has been analyzed. After Initialization is complete, three event objects are attached to the queue: S_listen_event: Socket named rild, main requeset & response channel S_debug_event: Socket named rild-Debug. requeset & response channel is used for debugging (the stream process is basically the same as s_listen_event, and only s_listen_event is analyzed later) S_wakeupfd_event: an unknown pipe used to actively wake up a queue. (You can use it to refresh the queue as mentioned earlier. For details, refer to the relevant sections on using it ).
|
This article is transferred fromWww.35java.com