Yes, there's crash-and-burn potential with the current RTS / GMP
interface. Three obvious solutions spring to mind:
- only activate the RTS allocation functions prior to invoking
a GMP primop.
- treat the GMP allocation functions that the RTS installs part
of the state that's stashed away when leaving Haskell &
re-installed upon return / entry.
- dynamically catch 'alien' uses of the RTS allocation functions &
re-route them to the default ones. (This will only work if the
external gmp-using code doesn't install its own allocators, of course).
All incur costs, so is it something that's practically worth fixing?
--sigbjorn
None of the above address (OS) thread safety (nor does GMP).
Having GHC (optionally) drop the GMP dependency would be
a fine development, methinks (for other reasons mainly, but also
including this one).
----- Original Message -----
From: "Marcin 'Qrczak' Kowalczyk"
I think there exists a problem. I haven't encountered it because I haven't tried to provoke it, but if I'm not mistaken it can cause big trouble.
Programs compiled by ghc set gmp's allocation functions to ones which allocate byte arrays on the Haskell heap, instead of the default malloc/free.
Now imagine a program or library which uses gmp for its own purposes and is linked with a program or library compiled with ghc. GMP's hooks are global, gmp is shared. Neither of allocation methods is suitable for the other side. So it won't work.
Is there a solution?
-- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users