Re: reentrantcy?
[Paul Elliott] 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. 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. No, what he meant is: if you link to libraries 'foo' and 'bar', and library 'foo' also happens to use 'bar', then at runtime there will be only one copy of 'bar' in your process address space. If library 'bar' is not reentrant and has shared state, this shared state will affect functionality used by both your base program and library 'foo'. This is all within a single process. Multiple processes don't affect each other unless, as others have noted, you explicitly set up shared memory and the like. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- 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/2020090157.ga2...@p12n.org
Re: reentrantcy?
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/2020040259.2ed09369@bigguy
Re: reentrantcy?
On Sunday, November 20, 2011 03:01:57 AM Peter Samuelson wrote: [Paul Elliott] 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. 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. No, what he meant is: if you link to libraries 'foo' and 'bar', and library 'foo' also happens to use 'bar', then at runtime there will be only one copy of 'bar' in your process address space. If library 'bar' is not reentrant and has shared state, this shared state will affect functionality used by both your base program and library 'foo'. This is all within a single process. Multiple processes don't affect each other unless, as others have noted, you explicitly set up shared memory and the like. Ok I understand what you meant now. I take it I am correct that non-reentrant libraries are allowed, and that non- reentrantcy is no reason to link staticly? Thank You for your answers. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: reentrantcy?
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? I guess you mean thread-safety rather than reentrancy. It's not reasonable to expect code with any shared data to be reentrant -- even basic building blocks like malloc() are not. On the other hand, if a library is not thread safe, I think this deserves a warning in the man page (unless thread safety would make no sense for that particular use). If the library has an actual reason to use globals -- with such a warning, being not thread safe is not a big flaw, and it can often be more efficient since the caller knows when the library will never be called concurrently -- which is the case a good majority of the time. -- 1KB // Yo momma uses IPv4! -- 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/2020094946.ga6...@angband.pl
reentrantcy?
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? I believe that it is better to write reentrant code and such code should be written when starting from scratch. But there is no reason not to use already existing non-reentrant code in non multi threaded applications. Am I correct? Also, I believe that non-reentrantcy, is not reason for static linking. The linker is capable of creating separate copies of writable global or static data, when programs are linked to a shared library. Am I correct? I ask these questions, because I have encountered someone who believes differently. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: reentrantcy?
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? It's not the linker that does it, it's the kernel. Separate programs have separate address space and can not influence each other over memory unless they make the effort of setting up shared memory. I believe that it is better to write reentrant code and such code should be written when starting from scratch. But there is no reason not to use already existing non-reentrant code in non multi threaded applications. Am I correct? There is also the case that a library can be used more than once without threads, for example when you use the library in your program and another library you link in also links to that library. If all linkings are shared, it is my understanding that the global state of the multiple-linked library would be shared by all references. -- Andreas Bombe -- 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/2020012714.ga4...@amos.fritz.box
Re: reentrantcy?
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 have separate address space and can not influence each other over memory unless they make the effort of setting up shared memory. I believe that it is better to write reentrant code and such code should be written when starting from scratch. But there is no reason not to use already existing non-reentrant code in non multi threaded applications. Am I correct? There is also the case that a library can be used more than once without threads, for example when you use the library in your program and another library you link in also links to that library. 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. 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 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. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: reentrantcy?
Paul Elliott pelli...@blackpatchpanel.com writes: 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. That's correct. Unless the programmer takes special action to force only one copy. That can only be done within a single program that's multithreaded (unless by special action you mean things like System V shared memory segments or something similar that's rather more than just normal static or global variables). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87ehx3b6v7@windlord.stanford.edu
