NFS servers can respond to requests in any order, and they do. In our
tests there is also some clustering to the responses; it could be
because eg. requests are served synchronously if the data is in the cache.
Introduce a hash table so that we are able to find the pdu quickly in
all cases, assuming random distribution of the responses.
Fixes a bug where the next pointer was not being explicitly set. We
were ok much of the time due to zero-filled memory, and also we need
this if the same pdu is re-queued.
When making many concurrent requests (as is likely in any performance
criticial application), the use of SLIST_REMOVE and SLIST_ADD_END are
a severe bottleneck because of their linear search.
I considered using a double-linked list but it was unnecessary to
allocate the additional memory for each list entry.
Instead, continue to use a single-linked list but retain:
* a pointer to the end of the list; and
* a pointer to the previous entry during a linear search.
The former would makes append operations O(1) time, and the latter
does the same for removal. We can do this because removal only happens
within the linear search, and there is no random access to the queue.
This makes it possible for multiple processes/contexts to use the same
target and (with some synchronization) avoid XID collissions across processes/contexts.
This patch switches libnfs over to use precompiled rpcgen files
and using ZDR. ZDR is a trivial reimplementation of XDR that is built in
into libnfs.
This removes the dependencies of rpc/xdr completely and allow us to build on any
system, even systems where rpcgen and librpc/libxdr are not generally available.
delete the previuous unmarshalling buffer when we start over and
process the second pdu to the initial call.
Or else we will leak memory very slowly when processing broadcast RPC replies