On Tue, 22 Oct 2013 16:36:45 -0700, "Edward Z. Yang" <[email protected]> writes:
> Hey Gergeley, > >> (obviously we would have to call mpz_free here and there, but that >> seems doable). > > Actually, this is precisely the problem. When is a GMP integer freed? > It can have pointers to it from objects on the heap, so this free should > only occur when the integer is dead, with no references from the heap. > How can that be arranged? Well, the garbage collector is responsible > for figuring this out. So why shouldn't they just live on the heap, and > then smoothly integrate with the existing garbage collector. > > The alternate strategy is to arrange that some sort of "callback" gets > invoked when an object dies. You can achieve this using our finalizer > support, but you pay an efficiency penalty and cannot guarantee that > the integers will get freed in a timely manner at all. Yes, I was thinking of this alternative strategy. I can understand that this may be slower in CPU, but can you please elaborate why would it be worse in memory, how the frees wouldn't happen in a "timely manner"? I thought finalisers are called when the referencee is GCd, so if we free the mpz in the callback, then where are we going wrong? >> More concretely: openssl BN uses the openssl_malloc function can only be >> overridden openssl wide. But if we link statically, than this override >> won't affect external openssl library bindings, because the openssl >> symbols in our object files won't even be exported, right? > > Only if literally two copies of OpenSSL are linked. This seems unlikely to > work the way you want it to. So we certainly don't want to replace the impossibility of wrapping libgmp in a hackage library with the impossibility of linking openssl :) Thanks for the input, if I go BN, I'll prioritize this to one of the first issues I tackle, because everyone is telling me that this is hard and I want to fail fast. Gergely _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
