Title: process_req_q()


If a message arrives but the message's request cannot be satisifed (for example, because there was no data available to be read), the message is put into a queue (e.g., srf_read_q). When the request can finally be processed, the first message in the queue is processed and then process_req_q() is called to process all of the remaining messages in the queue. process_req_q() does this by calling sr_rwio() repeatedly until either there are no remaining messages in the queue or sr_rwio() returns SUSPEND. (For example, sr_rwio() will return SUSPEND if there is not enough data to satisfy a read request.)

process_req_q() has three parameters:

mq - the first message in a linked list to be processed

tail - the address of the last message in the linked list

tail_ptr - the address of the relevant field of the file descriptor. For example, the relevant field for a read request will be the srf_read_q_tail field.

To see process_req_q() in action, consider the following example where messages requesting reads arrive yet there is no data waiting to be read:

Message 1 arrives, requesting a read operation. sr_rec() calls sr_rwio(), which checks whether the read flag was previously set. The read flag is not set, indicating that there has not been a previously unfulfilled read request. Therefore, the message is placed in the read queue (it becomes the head and the tail of the queue) and the protocol-specific read function is called (e.g., udp_read()). There is no data waiting to be read by the user process so the request is suspended (i.e., the suspend flag for the file descriptor is raised). Four further messages (messages 2-5) arrive and are placed at the end of the read queue. At this point, the queue is as follows:



Finally, data arrives. As a result, sr_put_userdata() is called twice. The first time sr_put_userdata() is called, the data requested by message 1 is copied to the user process. The second time sr_put_userdata() is called, sr_reply() is called, which sends a "REVIVE" message back to the FS specifying how many bytes were copied. Message 1 is then taken off the queue. At this point, the queue is as follows:



After sr_reply() returns, sr_put_userdata() calls process_req_q(), with a pointer to message 2 as the first argument, a pointer to message 5 as the second argument, and a pointer to the srf_read_q_tail field of the sr file descriptor as the third argument. process_req_q() repeatedly calls sr_rwio() until there are either no more messages or there is no more data available to satisfy the remaining requests. Let's assume that there is enough data to satisfy the first 2 messages. After satisfying the first two messages, the queue is as follows: