Re: Shared libraries / re-entrancy

mcdaniel@grex.ann-arbor.mi.us (Tim McDaniel) wrote:


> I'd like to have references to books, papers, documentation, et cetera, on
> how to implement shared libraries, but I don't know where to look.
>
> I'm told position-independent code and re-entrancy are necessary (well,
> the former is avoided if the library is always mapped to the same
> address), so I'd also appreciate any references on re-entrancy.


Basically re-entrant code means several processes can be running it at
once without interference. However a shared library is going to have a
shared data area, and therein lies the problem. To be re-entrant the only
uses of data in the shared library code must be either:


o read-only constants - clearly no conflict can arise if the data
isn't written


o global semaphores to control resources - possibility of deadlock must
                                                                                          be handled


o data controlled by such a semaphore - in which case must only be
referenced inside critical regions


o some other synchronisation stuff (event-counter is an example)




In most cases this means all workspace is malloced and/or provided by the
caller of the library routine, and the `global' state is really made
process-local. Clearly in Unix this has the advantage that each process
has the state for the library routines protected in it's own
address-space, which is rather important!


Of course the code part of the shared library will be read-only (not
self-modifying!)


Hope this sets you straight---if writing the library in an HLL, some
understanding of what the compiler generates for global data may be
required...
M. Tillotson Harlequin Ltd.
markt@uk.co.harlqn Barrington Hall,
+44 223 872522 Barrington, Cambridge CB2 5RG
--

Return to the comp.compilers page.
Search the comp.compilers archives again.