[Gc] crash in gc_mark_from with dlcose..

skaller skaller at users.sourceforge.net
Thu Jan 25 17:58:17 PST 2007


On Thu, 2007-01-25 at 16:31 -0600, Boehm, Hans wrote:

> It may be possible to make dlclose work under very restrictive
> conditions (which seems to be the best you can do even without a GC),
> but I haven't explored it.  (My attitude used to be that dlclose is so
> brittle anyway that it wasn't really worth dealing with, but people do
> seem to occasionally make good use of it.)

dlclose() is absolutely essential in some applications,
in particular long running servers which dynamically load and
unload client supplied resources.

You can imagine an application for a web server which is using
script compiled from HTML tags to generate a web page needing
to unload the compiled script! 

In fact there is a system that uses the BRD collect designed
for precisely this function, namely Nicholas Cannasse's
Neko system. Luckily it is a bytecode interpreter with a VM,
and such systems have much better control over resources,
including dynamic loading of bytecode (as opposed to shared
libraries).

Another system which does this job which doesn't use BRD
collector but would like to remain compatible with it
is my own Felix system: Felix *does* generate shared libraries,
and it *does* garbage collect them and eventually dlclose() them.

The constraints on shared libraries in these cases are
indeed very heavy .. independently of whether you're
using BRD collector or not, and hard or perhaps 
impossible (unfortunately) to enforce with the type system 
(due to Felix dependence on C/C++). I have some working
example of such plugins .. and the communication between
the 'mainline' and 'plugin' is severaly limited to ensure
they work (pasing plain old C data structures works,
eg floats and ints .. anything more is suspicious!)


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


More information about the Gc mailing list