http://bugzilla.suse.com/show_bug.cgi?id=1165351 http://bugzilla.suse.com/show_bug.cgi?id=1165351#c30 --- Comment #30 from Thomas Blume <thomas.blume@suse.com> --- (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. + */ --< -- You are receiving this mail because: You are on the CC list for the bug.