On Sat, Sep 07, 2002 at 10:02:27AM -0700, Jason R Thorpe wrote:
> On Sat, Sep 07, 2002 at 09:39:23AM -0700, Chuck Silvers wrote:
> 
>  > how is operation 1 per-LWP?  the address space is the same for each LWP
>  > in a process, so wouldn't they use the same ASN, etc?
>  > if the PCB is going to be per-LWP, shouldn't there be a corresponding
>  > structure that is per-proc, and wouldn't any address space information
>  > be in that structure instead of in the PCB?
> 
> The "about to switch to a LWP that uses this address space" is a 
> per-LWP operation.  I.e. "make sure this LWP's address space is ready
> to go, because I'm about to use it".

well, really that operation can contain both per-LWP and per-proc
components.  loading a different register set is a per-LWP thing.
switching address spaces is a per-proc thing.  if you switch between
two LWPs in the same proc, there's no need to switch address spaces
because you've already got the needed address space.


>  > (though I'd think that the per-LWP structure would be an LCB,
>  > leaving "PCB" per-process.  it does stand for "process control block"
>  > after all.)
> 
> Well, the PCB is part of u-area, which is a per-LWP thing.  There's
> really nothing left in the PCB if you split it into LCB and PCB, so
> it was a "don't make too many waves" kind of approach taken :-)

except that the address space is per-proc instead of per-LWP.
now that I think about it, any per-proc stuff related to the address space
probably just belongs in the pmap structure, so that procs sharing the pmap
can share it.  eg. there's no need for a vfork'd process to allocate a new
ASN until it execs, that kind of thing.  if the vfork'd process exits
before execing, allocating an ASN for it would be a waste.


>  > when would a process get a new address space while it has multiple LWPs?
>  > the address space changing out from under an LWP would cause a lot of problems,
>  > I'd think.  could you give an example of how this would work?
> 
> I don't have any real scenarios for this right now.  However, it was a
> hole in the previous pmap interface specification, IMO.

ok, let's wait until there's a practical use for such an operation
before we consider changing the pmap API for it.  :-)

-Chuck