Receiving a poll_diff request when the previous one has not been returned yet

Calls such as read and write are synchronous from the standpoint of an individual client--a request is made, and the requester blocks until a reply is received. This means that there can't ever be more than a single read request outstanding for a single client at a time. (The driver as a whole may be keeping track of many outstanding read requests in parallel, but no two of them will be from the same client file descriptor.)

As we mentioned in the previous section, the poll_diff callback is different from other callbacks. It is not part of a synchronous request/reply sequence that causes the client to block. It is also an interface to the kernel, not directly to the client. So, it is possible to receive a poll_diff request while there is already one outstanding. This happens if the kernel's poll state cache changes, causing it to notify the driver that it has a new cached value.

This is easy to handle; the client should simply

1. Destroy the old (now out-of-date) poll_diff request using the fusd_destroy function we saw in Section 8.2.3.
2. Either respond to or save the new poll_diff request, exactly as described in the previous section.

The next section will show an example of this technique.