You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The core framework currently evaluates the implementations listed in the SPD in order and on the first viable target device, will attempt to load the binary without regard to whether or not the binary actually exists. This results in errors at runtime about being unable to load implementations even if there are other viable implementations available.
One example of this is rh.HardLimit. If for some reason the executable device in the system's processor_name doesn't match either x86 or x86_64, the core framework moves on to the Java implementation (as it is next in the SPD). With all criteria met, the core framework then attempts to load the entrypoint for the Java implementation and fails right there, without then moving on to the Python implementation, or some other implementation the user has added to the SPD.
I propose that one of the first things the core framework should do is check for and then skip any implementation whose entrypoint does not exist on disk. This would allow for the framework to attempt all possible implementations without the user having to delete those implementation references from the SPD as a work-around.
The text was updated successfully, but these errors were encountered:
The core framework currently evaluates the implementations listed in the SPD in order and on the first viable target device, will attempt to load the binary without regard to whether or not the binary actually exists. This results in errors at runtime about being unable to load implementations even if there are other viable implementations available.
One example of this is rh.HardLimit. If for some reason the executable device in the system's
processor_name
doesn't match eitherx86
orx86_64
, the core framework moves on to the Java implementation (as it is next in the SPD). With all criteria met, the core framework then attempts to load the entrypoint for the Java implementation and fails right there, without then moving on to the Python implementation, or some other implementation the user has added to the SPD.I propose that one of the first things the core framework should do is check for and then skip any implementation whose entrypoint does not exist on disk. This would allow for the framework to attempt all possible implementations without the user having to delete those implementation references from the SPD as a work-around.
The text was updated successfully, but these errors were encountered: