Difference between revisions of "Talk:TUT:Writing a Dynamically Loadable Object"
From Net-SNMP Wiki
(Why is loading an object multiple times a problem?) |
m (Oh, right, dlopen behaves different from what I recalled.) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
How is loading the shared object multiple times problematic? As long as non-static symbols of the are not exported by default, both objects should live in their private little happy place. Actually, I doubt that setting <code>RTLD_GLOBAL</code> or similar would be a problem, because actually not symbol resolution takes place.. octo 21:45, 3 March 2009 (UTC) | How is loading the shared object multiple times problematic? As long as non-static symbols of the are not exported by default, both objects should live in their private little happy place. Actually, I doubt that setting <code>RTLD_GLOBAL</code> or similar would be a problem, because actually not symbol resolution takes place.. octo 21:45, 3 March 2009 (UTC) | ||
| + | |||
| + | The problem is that dlopening the same module a second time will return a reference to the same object as the first dlopen, so both copies will work with the same static data. magfr 2009-03-04T22:07 UTC | ||
| + | * Oh, that's right.. I should have checked <em>dlopen(3)</em> first.. octo 09:53, 5 March 2009 (UTC) | ||
Latest revision as of 09:53, 5 March 2009
How is loading the shared object multiple times problematic? As long as non-static symbols of the are not exported by default, both objects should live in their private little happy place. Actually, I doubt that setting RTLD_GLOBAL or similar would be a problem, because actually not symbol resolution takes place.. octo 21:45, 3 March 2009 (UTC)
The problem is that dlopening the same module a second time will return a reference to the same object as the first dlopen, so both copies will work with the same static data. magfr 2009-03-04T22:07 UTC
- Oh, that's right.. I should have checked dlopen(3) first.. octo 09:53, 5 March 2009 (UTC)
