Multiple instances of CUTEstModel can now coexist #389
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Each shared library dedicated to a SIF problem in a given precision is no longer linked to the same
libcutest_$precision.$dlext
. This previously caused issues when attempting to use multipleCUTEstModel
instances for the same precision simultaneously.By using static libraries instead, multiple problems can now be used simultaneously without conflict, as each library is independent from the others due to static linking.
I have modified the wrapper generator to add a
libsif
argument, which is of typePtr{Cvoid}
, returned byLibdl.dlopen
. EachCUTEstModel
now has alibsif
field.Users no longer need to manually call
finalizer(nlp)
; the garbage collector will handle it automatically. The only scenario where it might be necessary is if the user recreates a model with the same problem:It could be relevant in the case that the dimension of the problem is modified.
I have removed all global variables related to paths and the number of instantiated problems for a given precision.
I also updated the
README.md
to remove the@everywhere
trick, as it is no longer necessary.Note that we can't do this on macOS/Linux with Julia 1.6 because the Fortran compilers used to cross-compile binaries / Julia are incompatible with the
libgfortran
provided by the user's compiler.Fortunately, Julia 1.10 will soon become the new LTS version.
cc @tmigot