Re: How does a shared library work?
On 10/26/05, janne <jan.moren@lucs.lu.se> wrote:
> ons 2005-10-26 klockan 10:18 +0200 skrev Tshepang Lekhonkhobe:
> > Hello,
> > I wanted to avoid some searching headache by asking this question here:
> > I hear that the advantage of shared libraries is that there's only one
> > copy of that library in memory and I assume that the library is loaded
> > in memory only the first moment that a dependant package is run. But
> > who's reponsible for making sure whose turn it is to use that library
> > in case of several dependant packages requiring its use? Is it the
> > kernel?
>
> Neither. When you write something to be used as a shared library, it
> needs to be written to be "reentrant". That means the library must be
> able to have more than one process use it - even use the same exact code
> - at the same time. That is not as big a headache as it sounds.
>
> Remember that the code itself is never actually changed; it is in effect
> a fixed text run by the processes (the same is true of just about any
> code in fact). The problem is variables that do change, but that is
> neatly solved by the memory controller:
>
> Every process has its own mapped memory. This memory is divided into
> text segments (the actual code) and data segments (room for variables,
> stack and other data that changes as you run the application). When you
> use the shared library, its code is mapped into the processes memory.
> Note that it's not copied - there's still only one "real" copy - but the
> memory controller effectively makes it seem it's part of the rest of the
> program code.
Is the memory controller a part of the kernel?
Reply to: