Re: validity of foreign functions across saved images

Hi again,

I asked in March:
>> For example, currently I'm thinking about ways to provide an 
>API about how to revalidate foreign functions after being 
>restarted from an ancient image.

>> The thing is,
>> (DEF-ALIEN-ROUTINE #)
>> What is when you once evaluated these forms, saved your 
>image and restart from that saved image? Probably a crash. How 
>to address this portably?

Kevin Rosenberg answered:
>I see the problem. For MaiSQL, Pierre worked hard to keep the crypt
>foreign call to be evaluated at load time for the postgresql-native
>interface. [...] His solution was a
>bit cumbersome.  I do something similar in CLSQL with UFFI in the 
>postgresql-socket interface.

>For ACL and LW, which don't evaluate the function address 
>during compile
>and load times, there is not the same problem with saving an image that
>has the foreign call definitions at the top level.
When do they do it?

I'd like to ask again how ACL & LW do it. Do they systematically perform late-binding, e.g. at every invocation, ask for the current address?
E.g. via dlsym()? I wouldn't believe that (because it sounds like loosing too much performance).

Or do the supporting (UNIX) OS guarantee that the symbols will always be loaded to the same addresses (which sounds unbelievable for arbitrary dlopen())?

Or do they some kind of dependency maintenance on the foreign addresses, and reopen as needed when found invalid?
I don't believe this either, since I think Allegro really uses integers for FFI addresses - you can't maintain dependency relations (i.e. detecting the library was closed) using Lisp integer objects, esp. fixnum "objects".


I'm still seeking a concept for doing this for CLISP (or whatever) across saved images.
1. Fast start: only provide REALLY-OPEN-LIBRARY and REALLY-CLOSE. No provision for maintaining stuff valid pointers images.
This is enough for people to play with source and compiled Lisp files.

2. Provide something more elaborate for declaring foreign functions w.r.t. a library and record all functions derived from that library in a table.
2b. Provide some REOPEN-LIBRARY that will also fix in place all foreign function objects with new pointers.
2b. Or just a FOREIGN-LIBRARY factory-style constructor that'll take care of opening only once and revalidating all known function pointers - if it can!
2b1. What to do if some function frob is not available in the shared library of the current system while it was on the earlier system where the table was generated? Cause FOREIGN-LIBRARY to fail? Output a message to stderr? Leave the one function invalid so an error will be seen only when called?
3. Does CLISP's current foreign function structure provide for enough information to (re)do late-binding?

Thanks for your help,
	Jorg Hohle.