Comment # 30 on bug 1165351 from Thomas Blume

(In reply to Thorsten Kukuk from comment #29)

> 2. I seldom agree with Poettering, but here I do: we need to fix the tirpc
> implementation. Don't allocate an array for all possible fd numbers, but
> instead use a linked list or something similar. Yes, this will be slower,
> but if I look at the usage, I don't think this is a real problem on todays
> CPUs.

Thanks Thorsten, interestingly, even the original patch (from 2007!) states
that the implementation is silly:

-->
+/*
+ *      This machinery implements per-fd locks for MT-safety.  It is not
+ *      sufficient to do per-CLIENT handle locks for MT-safety because a
+ *      user may create more than one CLIENT handle with the same fd behind
+ *      it.  Therfore, we allocate an array of flags (vc_fd_locks), protected
+ *      by the clnt_fd_lock mutex, and an array (vc_cv) of condition variables
+ *      similarly protected.  Vc_fd_lock[fd] == 1 => a call is active on some
+ *      CLIENT handle created for that fd.
+ *      The current implementation holds locks across the entire RPC and
reply.
+ *      Yes, this is silly, and as soon as this code is proven to work, this
+ *      should be the first thing fixed.  One step at a time.
+ */
--<