On 12/17/13, 8:34 PM, John Baldwin wrote:
On Tuesday, December 17, 2013 1:17:45 pm Mateusz Guzik wrote:
On Tue, Dec 17, 2013 at 11:41:49AM -0500, John Baldwin wrote:
On Saturday, December 14, 2013 11:11:43 pm Mateusz Guzik wrote:
Author: mjg
Date: Sun Dec 15 04:11:43 2013
New Revision: 259407
URL: http://svnweb.freebsd.org/changeset/base/259407
Log:
proc exit: don't take PROC_LOCK while freeing rlimits
Code wishing to check rlimits of some process should check whether it
is exiting first, which current consumers do.
Does this measurably reduce contention?
No, this is just a cosmetic change I did while doing some other work
with rlimits.
It would use some more cosmetic work (e.g. no reason not to
lim_free(p->plimit); p->p_limit = NULL) and maybe I'll get to that
later unless this kind of stuff is unwanted.
I find it useful to leave the locking in place so it is clear that p_limit is
always written to with the lock held. If we ever got a static analyzer that
understood locking rules then leaving this locking in would reduce false
positives. When I first did locking for fields in struct proc I did it by
hand based on grepping the source tree for all uses of a field and ensuring
they were locked. I think it might be more confusing later on for another
reader to see unlocked access and then have to think about why that is safe.
leave the locks there but commented out with an explanatory comment.
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
