Hi Dai, >> * Besides clnt_max_conns, there are other static declarations, which >> need to be removed. Your proposed changed does not fix these. > Yes, this webrev was intended to show the proposed change for the load > balancing issue. > I removed only the static declaration for clnt_max_conns for testing > purpose.
OK. > My main concern is the stability and performance of the system when > changes are made to a sensitive > area such as rpcmod. Simpler change is easier to understand and verify, > less chance of introducing new > bug, less impact to performance of the code. Now I got your point and I agree in the general case. I am also aware of the significance of this piece of code and I do definitely want to avoid any regressions here. In this particular case, however, I think we should really aim for a solution which also does away with some legacy code with sets an initial barrier for understanding the code. By not removing this code, that barrier would be raised, IMHO, because the solution you suggested adds even more complexity. >> I would also like to point our that I have reduced the complexity for >> dooming entries (will be done in one go trough the list rather than >> starting all over when an entry is doomed), that I hope to have made >> the function more concise and that I hope to improve on maintenance by >> adding comments. > I'm not sure if we need to address this since clnt_max_conns is not > expected to change frequently. Agree. I did this because the change was straight forward and contributed to code clarity, IMHO. By the way, I just noticed that it is probably required to hold cm_entry->x_lock when juggling with list linkage pointers. Nils
