[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shared libs.



> There is an easy way to solve the problem of local (to a process) variables.
> Whatever you do you'll need stub routines to link to when you build the
> executable, so why not get these to allocate all the variables in a block
> and then pass a variable base pointer to the shared routine?
> 
> This would only have to be done once. The second, third and n'th time the
> routine was called all that would be needed would be to pass the base
> pointer to that shared routine.
> 
> The advantage is that this scheme is simple.. and hence it's likely to work.
> 
> The only problem you may have is if the program is pre-empted whilst inside
> the shared routine, in which case we have to make sure that the routines are
> fully re-entrant, say by using the current pid as a redirection pointer to
> local variables or something (though this may need some help from the
> kernel). Alternatively, you can make all the shared library calls atomic.
> It's up to you.
> 

It could be done even simpler than that: As the data section of a
shared library must exist separately in each process, we can allocate
its space already at link time (not at load time). The stub routines
are then called with the base pointer to the memory in the process'
bss area. This avoids any reentrancy problems. It also avoids the need
to deallocate any of the shared library's data sections when the
program is finished.

> Steve
> 
> -- 
> ---------------------------------------------------------------------------
> Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
> E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
> Tel:- Oxford (01865) 282110 (UK) or +44 1865 282110 (International).