On Sat, 19 Nov 2011 23:22:34 -0600 Paul Elliott <pelli...@blackpatchpanel.com> wrote:
> On Saturday, November 19, 2011 07:27:14 PM you wrote: > > On Sat, Nov 19, 2011 at 07:03:19PM -0600, Paul Elliott wrote: > > > Is there any requirement that a shared library be reentrant, if the > > > upstream wrote it that way? > > > > > > Am I correct in my assumption, that although non-reentrancy presents a > > > problem for multi threaded programs, it is not a problem for > > > multi-programming, that is two programs using the same shared library at > > > the same time, because the linker will assure that the separate programs > > > will have separate copies of any writable global or static data? > > > > A > > It's not the linker that does it, it's the kernel. Separate programs The linker sets flags that the kernel used to enforce, or not that requirement. > > > B > > If all linkings are shared, it is my understanding that the global state > > of the multiple-linked library would be shared by all references. this is true. both linkings are with in the same process space. program A includes a library B and one C. B is linked also with C. if A calls C function F() that sets a global variable then B will see that value. If there is "state" to the value the state that A experiences may be inconsistent. > > Statement A and B above seem to contradict each other. > > If global state means global variables, my experiments show that B is not > true > but A is true. the B case has both in the same process. its not directly related to threading. If there were 2 copies of B running (B and B') then they wouldn't share any data that was not explicitly marked as share-able. > > The state of a global variable in one program does not effect the state of > the > same global variable in another program that links the same shared library. > Both programs have seperate copies of static or global writable varriables of > the shared library. > Unless the programmer takes special action to force only one copy. > > Best Wishes. > Hope that helps Joe -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111120040259.2ed09369@bigguy