Tue, 20 Nov 2001 18:06:18 -0800
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?
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" <email@example.com>
Sent: Tuesday, November 20, 2001 15:52
> 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 * firstname.lastname@example.org http://qrczak.ids.net.pl/
> Glasgow-haskell-users mailing list