I think items 1-4 are taken care of now (though I'll run some further
tests). However, I'm still unsure about item 5. Resolving an absent
libgmp.so gracefully will mostly reimplement functionality of
SB-ALIEN::TRY-REOPEN-SHARED-OBJECT by disabling an automatic reload
during saved core startup.
One can make it more gracefully wrt. the path of the shared lib with the
>From your POV shall I proceed in this direction or can we live with an
error when no libgmp.so can be found during loading of the saved core.
PS: I also accidentally pushed the current state of mpfr.lisp and didn't
bother to roll back. Though it is not loaded by the ASDF system file and
only has very low-level functionality at the moment.
On 06/11/2013 05:59 PM, Paul Khuong wrote:
> crimsonf@... wrote:
>>> So, it's been a couple weeks since I looked at your repository, but
>>> here's the list I last had of issues/things to look at before merging:
>>> 2. Make sure the enable/disable GMP functions work when used multiple
>>> times in a row or concurrently (re-entrancy isn't a big deal for me);
>> According to the documentation GMP is reentrant safe, if not explicitly
>> configured with --enable-alloca=malloc-notreentrant. The older, deprecated
>> and non-safe, functions are not part of SB-GMP interface. Since the
>> interface functions allocate new bignums I think we should be fine. The
>> only problem is the use of the same random state in different threads,
>> though this is the same problem one has in a pure Lisp context as well.
> I was thinking of install-gmp-funs/uninstall-gmp-funs, actually. The
> lock/unlock package logic looks like it wants a mutex on threaded builds.
> I also worry about two libraries installing and uninstalling gmp-funs.
> That's why I think the contrib should enable by itself, and offer a
> local way to disable/re-enable. If that's around, install-gmp-fun and
> uninstall-gmp-funs can be %-prefixed and only exposed for people who
> *really* know what they're doing.
> I trust GMP itself to be thread-safe ;) As for the random state, it
> seems to me the interface works with an explicit state argument. That's
> good enough for me.
>>> 4. (Not sure) toggle the use of GMP via a special variable. This could
>>> be useful to improve performance, look for bugs, and eventually expose
>>> multiple switch-over policies... and a special binding is thread-safe,
>>> unlike global redefinitions;
>> This would be an additional if in the call functions, i.e. all the gmp-...
>> functions at the end of gmp.lisp. Do we really want that? On can uninstall
>> the transparent integration via (uninstall-gmp-funs) though I admit that
>> is not as comfortable and elegant as binding a special variable.
> (Actually, the special variable lookup is likely to have more of an
> impact than a branch ;) If we only perform a special lookup before
> calling out to C, I'm pretty sure the difference will be noise. It's
> just that I don't see any other way to enable the changes in a single
> thread, and extremely well-behaved libraries might want to do that.
>>> 5. What happens after a core is saved? Can it degrade gracefully in the
>>> absence of libgmp when it's thawed?
>> OK, will have to think about that. Are there any standard solutions to
>> this problem?
> I think sb-alien automatically reloads libraries on restart, but that
> doesn't work very well if the paths have changed (e.g. we're running on
> a different machine). We have sb-ext:*save-hooks* and
> sb-ext:*init-hooks*; they would be useful to disable GMP before saving,
> and to try and re-enable it during reinitialisation.
>>> MPFR would be something else altogether. Extending the meaning of
>>> standard CL types would be an interesting journey through both the spec
>>> and Python.
>> I have continued on this road though have not pushed anything yet. I will
>> probably wait until the first version with bignum-only support is merged.
>> For the moment there is no transparent integration with the standard CL
>> functions or floating-point types.
> This would easily be useful. I'm not sure that transparent magic is a
> win here, but I can easily see something like sb-mpfr:+ that downgrades
> to cl:+ at compile-time depending on derived argument types.
> Paul Khuong
> This SF.net email is sponsored by Windows:
> Build for Windows Store.
> Sbcl-devel mailing list