|Shared libraries firstname.lastname@example.org (1993-01-16)|
|Re: Shared libraries / re-entrancy email@example.com (1993-01-20)|
|From:||firstname.lastname@example.org (Mark Tillotson)|
|Organization:||Harlequin Limited, Cambridge, England|
|Date:||Wed, 20 Jan 1993 13:11:56 GMT|
email@example.com (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
o global semaphores to control resources - possibility of deadlock must
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
Hope this sets you straight---if writing the library in an HLL, some
understanding of what the compiler generates for global data may be
M. Tillotson Harlequin Ltd.
firstname.lastname@example.org Barrington Hall,
+44 223 872522 Barrington, Cambridge CB2 5RG
Return to the
Search the comp.compilers archives again.