0

The goal is to emulate multi-threaded behavior for a .so which is not thread-safe. Memory is plentiful, not a problem. What is important for me is down-calls via JNI. What is not important is up-calls and sharing anything between .so instances (the goal is complete isolation).

I have heard that it is possible to link a shared lib more than once, but I have not seen anyone actually do it.

There is an opinion that doing this is a bad idea, but I am not convinced by the argument.

Is this a good/bad idea, and why?

If this turns out to be a good idea under certain conditions, where can I read more about it? Can anyone share some code that does this?

Let me add that making .so thread-safe is not really an option, and that mutex is the current implementation which I am trying to improve.

Community
  • 1
  • 1
user443854
  • 7,096
  • 13
  • 48
  • 63

1 Answers1

0

The idea of a shared library is just to share a common code segment among multiple applications.

Once you realized this basic fact, you'd realize that what you're trying to do doesn't makes sense. Because the memory allocation will be within your process space.

Raj
  • 80
  • 5
  • 1
    I understand that what I am trying to do is against the idea of a shared library. This is not the point in question. The point is to trick JVM into linking same .so multiple times (via LD_LIBRARY_PATH manipulation or else -- does not matter). By saying "doesn't make sense" -- do you mean this is not possible? Or do you mean it does not make sense to **you**, and you would do it differently? – user443854 May 31 '11 at 15:08
  • What I was trying to say that even if you manage to do this, where would the variables be allocated the memory at? Assuming its not a thread-safe library, so its not entirely re-entrant; say presence of a static variable. You think if you'd link the library multiple times there will be multiple memory allocations for the same static variable? Sounds like a deal breaker to me! – Raj May 31 '11 at 15:42
  • Agreed on static variables, deal breaker indeed. What about using different namespaces to make them namespace-static, not process-static? I am just throwing out ideas, not that I know of a way to achieve this. The reason I started this thread is because I *think* I've heard of this being done. – user443854 May 31 '11 at 15:59
  • You make them namespace static (you're actually making the library re-entrant) and that shared library of yours becomes thread-safe. I assumed you didn't had the code for the library or you didn't wanted to touch it. – Raj Jun 01 '11 at 07:40
  • I do have the library source code, but I am reluctant to touch it for fear of breaking it. If I can touch it in minimal, easy to understand way, that's acceptable. I would really like to speak with someone who has done this, else I might resort to trial and error: create mock lib with a couple of static vars, and find out what minimal amount of code modification will achieve separation of static vars. BTW, thanks for the discussion. – user443854 Jun 01 '11 at 13:15
  • which platform are you working on? this seem like a platform dependent thing, which beats the purpose of using Java. however, if you plan to use the application on a single platform, it would be easier for you to research the subject. good luck. – Raj Jun 01 '11 at 19:36