GMP

[Sigbjorn Finne]

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" <qrczak@knm.org.pl>
To: <glasgow-haskell-users@haskell.org>
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