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 <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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 ? 
:
:David Xu

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>