Runtime.loadLibrary() and unloadLibrary() on POSIX. #211

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@bithavoc

This comment has been minimized.

Show comment
Hide comment

+1

@MartinNowak

This comment has been minimized.

Show comment
Hide comment
@MartinNowak

MartinNowak May 21, 2012

Member

We need a full blown library initialization.
We also need a shared runtime instead of a GC proxy.

Member

MartinNowak commented May 21, 2012

We need a full blown library initialization.
We also need a shared runtime instead of a GC proxy.

@alexrp

This comment has been minimized.

Show comment
Hide comment
@alexrp

alexrp May 21, 2012

Member

So what is the plan for these functions?

Member

alexrp commented May 21, 2012

So what is the plan for these functions?

@bithavoc

This comment has been minimized.

Show comment
Hide comment
@bithavoc

bithavoc May 21, 2012

@alexrp ++
@dawgfoto what do you mean, will this patch work or not? :)

@alexrp ++
@dawgfoto what do you mean, will this patch work or not? :)

@klickverbot

This comment has been minimized.

Show comment
Hide comment
@klickverbot

klickverbot May 21, 2012

Member

I think the issue is that the patch itself is correct, but not enough to smoothly support shared libraries on Posix, because all kinds of stuff will still break behind your back. Martin already did some work on this in the branch at his repo he linked, but as far as I know, there is still some more to do – you might want to join forces.

Member

klickverbot commented May 21, 2012

I think the issue is that the patch itself is correct, but not enough to smoothly support shared libraries on Posix, because all kinds of stuff will still break behind your back. Martin already did some work on this in the branch at his repo he linked, but as far as I know, there is still some more to do – you might want to join forces.

@MartinNowak

This comment has been minimized.

Show comment
Hide comment
@MartinNowak

MartinNowak May 21, 2012

Member

Linking against shared libraries will work soon but loading shared libraries at runtime
will still take a while. There are two major technical issues to solve.

  • Runtime.unloadLibrary will probably have to go. Due to GC one cannot deterministically free all references to a loaded library. The latest idea for this was to put the address range under control of the GC and let him release the library.
  • There is no solution yet for per-thread initialization when you load a C library at runtime that depends on a D library. Basically we need to traverse the dependency DAG of a library but the only feasible solution I found was to poke around in the dlopen handle.
Member

MartinNowak commented May 21, 2012

Linking against shared libraries will work soon but loading shared libraries at runtime
will still take a while. There are two major technical issues to solve.

  • Runtime.unloadLibrary will probably have to go. Due to GC one cannot deterministically free all references to a loaded library. The latest idea for this was to put the address range under control of the GC and let him release the library.
  • There is no solution yet for per-thread initialization when you load a C library at runtime that depends on a D library. Basically we need to traverse the dependency DAG of a library but the only feasible solution I found was to poke around in the dlopen handle.
@bithavoc

This comment has been minimized.

Show comment
Hide comment
@bithavoc

bithavoc May 22, 2012

I get it, that's like others GC'd/managed environments works(AppDomain.Unload in the CLR) and that sounds like a good plan for the future. However, (and this is just a thought) I think that a partial implementation of this feature that at least let the developer load D shared libraries would be very useful.

IMHO, this will be used mostly to load plugins, plugins will modify the environment and do random stuff. From the application point of view it's easier to just restart the process in order to reload the new "catalog" of plugins.

Developers can use dlopen for C shared libraries and loadLibrary for D shared libraries. I don't think unloadLibrary is that necessary at this point, it's always better to just restart the process. In the future, if there will be an implementation of unloadLibrary, it will just mark the library to be unloaded eventually by the Runtime/GC.

So I would vote for a partial implementation of 'loadLibrary' and defer 'unloadLibrary' until we can afford the unload libraries in a safe way by a shared Runtime, etc.

Again, this is just a thought.

I get it, that's like others GC'd/managed environments works(AppDomain.Unload in the CLR) and that sounds like a good plan for the future. However, (and this is just a thought) I think that a partial implementation of this feature that at least let the developer load D shared libraries would be very useful.

IMHO, this will be used mostly to load plugins, plugins will modify the environment and do random stuff. From the application point of view it's easier to just restart the process in order to reload the new "catalog" of plugins.

Developers can use dlopen for C shared libraries and loadLibrary for D shared libraries. I don't think unloadLibrary is that necessary at this point, it's always better to just restart the process. In the future, if there will be an implementation of unloadLibrary, it will just mark the library to be unloaded eventually by the Runtime/GC.

So I would vote for a partial implementation of 'loadLibrary' and defer 'unloadLibrary' until we can afford the unload libraries in a safe way by a shared Runtime, etc.

Again, this is just a thought.

@alexrp alexrp referenced this pull request in dlang/dmd Sep 13, 2012

Closed

Link to libdl on non-BSD POSIX systems. #941

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment