load-foreign-library behaviour

Luís Oliveira luismbo at gmail.com
Mon May 16 16:33:46 UTC 2022


I believe Stelian introduced that hack for the sake of
CLOSE-FOREIGN-LIBRARY. Can we keep track of handles in a smarter way?
(Not all Lisps expose the dlopen() handle IIRC.) Or perhaps
CLOSE-FOREIGN-LIBRARY could call dlclose() repeatedly? Subject to an
option, perhaps. (Does it return nonzero if the library was already
unloaded?)

Stelian, what was your use case?

On Mon, 16 May 2022 at 10:47, Madhu <enometh at meer.net> wrote:
>
>
> LOAD-FOREIGN-LIBRARY and USE-FOREIGN-LIBRARY have the undesirable
> side-effect of closing the library first before loading it. While
> unloading doesn't seem to work on ccl, on Lispworks, mkcl and ecl this
> actually does what is intended, but it has unfortunate consequences
> with some libraries which perform initializations which are not undone
> when they are unloaded. reloading the library is disastrous.
>
> the names LOAD-FOREIGN and USE-FOREIGN have nothing to suggest there
> is unloading involved.  The expectation is that unloaded libraries are
> loaded. If a library is already loaded there is no expectation that it
> will be touched.  This is the desired behaviour.
>
> In my case I have been bitten by USE-FOREIGN-LIBRARY and I changed it
> to not unload with the following patch. Can anyone suggest anything
> better?
>
> [Please don;t ask me to open a github issue, I've tried using the
> github channels since 2019 absolutely no success]
>


-- 
Luís Oliveira
http://kerno.org/~luis/



More information about the cffi-devel mailing list