Does CMUCL garbage-collect object (*.o) code? What if I load it,
change *.o on disk, load it again, repeat ? What about libraries
(shared and static) ?
>>>>> "df" == David Fisher <·············@yahoo.com> writes:
df> Does CMUCL garbage-collect object (*.o) code?
no, neither foreign code nor foreign data are garbage collected.
df> What if I load it, change *.o on disk, load it again, repeat ?
df> What about libraries (shared and static) ?
if you limit yourself to shared libraries that you load with
SYS::LOAD-OBJECT-FILE, you may be able to get away with the following
(for platforms that use dlopen, ie at least x86/Linux and SPARC/Solaris).
,----
| (defun reload-shared-libraries ()
| (loop :for lib-entry in sys::*global-table*
| :for (sap . lib-path) = lib-entry
| :when lib-path :do
| (sys::dlclose sap)
| (let ((new-sap (sys::dlopen (namestring lib-path)
| (logior sys::rtld-now sys::rtld-global))))
| (when (zerop (sys:sap-int new-sap))
| (error "Couldn't open library ~S: ~S" lib-path (sys::dlerror)))
| (setf (car lib-entry) new-sap)))
| (alien:alien-funcall (alien:extern-alien "os_resolve_data_linkage"
| (alien:function c-call:void))))
`----
When a shared library changes, make sure that CMUCL is in a quiescent
state wrt calls to foreign code, then call RELOAD-SHARED-LIBRARIES.
Please consider this hack to be several light-years away from being
officially supported.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>