DragonFly commits List (threaded) for 2006-05
Re: cvs commit: src/sys/conf files src/sys/kern init_main.c kern_acct.c kern_exit.c kern_fork.c kern_plimit.c kern_resource.c kern_synch.c syscalls.master src/sys/sys kern_syscall.h proc.h resourcevar.h
:Matthew Dillon wrote:
:> Document how LWPs will have to be handled - basically we will have to
:> unshare the resource structure once we start allowing multiple LWPs per
:> process, but we can otherwise leave it in the proc structure.
:Why should each LWP have its RLIMITS ?
All the LWPs share one limits structure (since the limits structure
is embedded in the process, not the lwp). But this limits structure
might have been inherited from other unrelated processes when the
threaded program was fork/execed.
When a process tries to create a second LWP (in the future, when that
function is supported), the limits structure needs to be disconnected
from those other unrelated processes so the threaded process has sole
ownership of it.
If we don't do this, then any LWP trying to modify a resource limit
would have to perform the copy-on-write to replace the process's
p_limits structure in the face of other LWPs potentially also accessing
proc->p_limits. We would have to obtain a spinlock on the process
AND the limits structure to prevent a race.
But if when a process tries to rfork a second thread we unshare the
limits structure from other unrelated processes, now proc->p_limits
is set in stone and all LWP threads will only have to spinlock
the limits structure (and not have to spinlock the proc structure to
get to the limits structure).
So that rule greatly reduces code complexity.