cvs commit: hugs98/lib/exts ForeignPtr.hs MarshalAlloc.hs hugs98/src HsFFI.h builtin.c
reid 2002/09/18 09:09:22 PDT Modified files: lib/exts ForeignPtr.hs MarshalAlloc.hs src HsFFI.h builtin.c Log: To bring Hugs into line with FFI RC7, I added: void hs_perform_gc(void); mallocForeignPtr mallocForeignPtrBytes To add the last two, I had to get hold of &free from somewhere. I decided that MarshalAlloc was the best choice but this isn't in the ffi spec - I'll mail the ffi folk about it. Revision Changes Path 1.6 +14 -0 hugs98/lib/exts/ForeignPtr.hs 1.3 +4 -1 hugs98/lib/exts/MarshalAlloc.hs 1.7 +1 -1 hugs98/src/HsFFI.h 1.33 +7 -2 hugs98/src/builtin.c
On Wed, Sep 18, 2002 at 09:09:22AM -0700, Alastair Reid wrote:
To bring Hugs into line with FFI RC7, I added:
void hs_perform_gc(void); mallocForeignPtr mallocForeignPtrBytes
To add the last two, I had to get hold of &free from somewhere. I decided that MarshalAlloc was the best choice but this isn't in the ffi spec - I'll mail the ffi folk about it.
How about making it private in ForeignPtr? This change breaks the new library setup, because it gets MarshalAlloc from fptools but ForeignPtr from you. The alternative would be to duplicate ForeignPtr, but that would be a waste.
How about making [&free] private in ForeignPtr? This change breaks the new library setup, because it gets MarshalAlloc from fptools but ForeignPtr from you. The alternative would be to duplicate ForeignPtr, but that would be a waste.
I think it logically belongs in the same module that provides malloc and free. Suppose we had two memory allocators, you'd have to be sure to use the right 'free' for each object and that free ought to come from that same place that provides the malloc you allocated with. (In my other life as an OS componentware hacker, we do sometimes have multiple mallocs and being sure to use the right one is a concern so this issue is very much in my mind.) I must admit that I don't quite understand how it broke things though... -- Alastair
On Thu, Sep 19, 2002 at 09:13:46PM +0100, Alastair Reid wrote:
I must admit that I don't quite understand how it broke things though...
The new library setup gets Foreign.Marshal.Alloc straight from fptools/libraries/base. But Foreign.ForeignPtr is system-dependent, so it's made from lib/exts/ForeignPtr by making the module names hierarchical. From the perspective of the new setup, you've changed one without changing the other.
participants (3)
-
Alastair Reid -
Alastair Reid -
Ross Paterson