wanted: sb-alien:foo-error and restarts for failed sb-alien:load-shared-object

Bug #905840 reported by Nikodemus Siivola
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Triaged
Wishlist
Nikodemus Siivola

Bug Description

The condition should at least include the pathname.

USE-VALUE, STORE-VALUE, and CONTINUE seem like apropos restarts.

Revision history for this message
Nikodemus Siivola (nikodemus) wrote :

also: *LOAD-SHARED-OBJECT-ERROR-HANDLER*

Point being that people can set that in saved cores to handle errors during init.

also: export and document SHARED-OBJECT-FOO accessors from SB-SYS (or maybe SB-ALIEN?)

Revision history for this message
Nikodemus Siivola (nikodemus) wrote :

Proposed shared object API extensions:

(defun map-shared-objects (function)
  "Calls FUNCTION with two values for each shared object loaded: \(1) PATHNAME
argument used to load it -- and usable with UNLOAD-SHARED-OBJECT to unload it.
\(2) A boolean designating if the shared object will be retained when the core
is saved, ie. false if :DONT-SAVE T was passed to LOAD-SHARED-OBJECT earlier."
  ...)

(defun rename-shared-object (old-pathname new-pathname)
  #!+sb-doc
  "Changes the pathname associated with a shared object from OLD-PATHNAME to NEW-PATHNAME:
when the core is saved and later restarted, NEW-PATHNAME is used to try to reload
the shared object instead of the OLD-PATHNAME. Signals an error if OLD-PATHNAME is not
associated with a shared object."
  ...)

I think these should be enough to cover most cases we're interested in, and seems easier than exposing internal objects sanely.

Changed in sbcl:
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.