On 10/26/05, janne <[EMAIL PROTECTED]> 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?
