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" To: Sent: Tuesday, November 20, 2001 15:52 Subject: GMP

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