Re: Cheap ForeignPtr allocation
> Hi Folks, I'd like to propose two new functions for the ForeignPtr > interface: I'm a bit uneasy about this. It seems like decisions made on technological grounds (i.e., because they enable an optimization) tend to date rather quickly because the technology tends to change too. The functions may cover a fairly common case of using ForeignPtrs (though I've never used ForeignObjs or MallocPtrs that way) - but most code doesn't use ForeignPtrs so it's a common case of an uncommon thing. It'd be a bit more compelling if the combos made things easier (as the withFoo functions do) or raised the level of abstraction. I'm inclined to say: add it to GHC for now and prod us again once a decent body of examples builds up. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Proposed change to ForeignPtr
[Now that we've gotten the library specification issue out of the way, I'd like to revive discussion of this topic. Last time we discussed it, there seemed to be concensus that we would make a change but I didn't get much response when I made a concrete proposal. I'd like to resolve this promptly so that the impending Hugs release can match what the spec says (or vice-versa...).] Since requiring ForeignPtr.newForeignPtr would require preemptive concurrency (see previous discussion), I propose the following changes: 1) Add these functions: makeForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a) attachForeignPtrFinalizer :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO () It is implementation defined whether the free functions are allowed to call Haskell functions. 2) Remove newForeignPtr and addForeignPtrFinalizer [GHC can go ahead and list them as non-standard extensions] There's a minor issue about whether the old function names should be reused (leaving GHC to come up with its own names) or not. I have ceased to care either way. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: Cheap ForeignPtr allocation
> I vaguely remeber that in the context of the withForeignPtr > discussion we where once trying to achieve some similar > effect (but couldn't come up with something that would > work). Do you remember? Uh, my memory's a bit vague too :-) For a long time we were trying to get cheap allocation/freeing for temporary storage, i.e. a cheap alloca. We managed to achieve that when I realised I could pull a trick with GHC's garbage collector and have "pinned" objects as long as they don't contain any pointers into the heap. So instead of using malloc()/free() for alloca, we allocate a pinned ByteArray# and let the GC free it. (it needs to be pinned so that it can be passed to foreign functions which might re-enter the RTS and trigger GC, etc.) This proposed extension to ForeignPtr is just taking the idea one step further: we can use the same trick for ForeignPtrs too, at least in the common case where you want the finalizer to free() the object again. > Does this, then, effectively solve > this old problem? Wouldn't you want newXXX and withXXX > variants of the above, too? The two functions I mentioned are all that's needed: mallocForeignPtr :: Storable a => IO (ForeignPtr a) mallocForeignPtrBytes :: Int -> IO (ForeignPtr a) they both do the job of a combined malloc/newForeignPtr. withForeignPtr still works fine with a ForeignPtr constructed this way. Cheers, Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Library archives
"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote, > | .NET is a different beast from other calling conventions in > | that you may want to compile Haskell ccalls to .NET > | intermediate language. In other words, it is about being > | able to implement ccall *on* .NET. Thus, the mix. > > I think that is exactly the issue. > > | At the moment, there doesn't seem to be much support for > | [lib]. The last message from SimonPJ (a while ago) on this > | issues also seems to indicate that he isn't to bothered about > | it. But AFAIK he is away at the moment. > > So let's omit it for now; but we will need to think about what to > do when someone really does do a Haskell-on-.NET binding. So, overall this point is settled, then; implying that we stick with Alastair's recent change of the spec in that regard. Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Cheap ForeignPtr allocation
"Simon Marlow" <[EMAIL PROTECTED]> wrote, > I'd like to propose two new functions for the ForeignPtr interface: > > mallocForeignPtr :: Storable a => IO (ForeignPtr a) > mallocForeignPtrBytes :: Int -> IO (ForeignPtr a) > > (the names can change, of course). The implementations are trivial in > terms of existing things: > > mallocForeignPtr = do > p <- malloc > newForeignPtr p free > > mallocForeignPtrBytes size = do > p <- mallocBytes size > newForeignPtr p free > > However, in GHC we can provide a far more efficient implementation by > using pinned ByteArray#s, avoiding the overhead of malloc()/free() and > the finalizer. Since this is quite a common idiom when using > ForeignPtrs, I think it's a good case to optimise. > > I did a little test, and using the above functions gave a 6x improvement > in a small example which just repeatedly allocated a new ForeignPtr and > passed it to a foreign function. > > The GHC implementation is to extend the ForeignPtr type like this: > > data ForeignPtr a > = ForeignPtr ForeignObj# > | MallocPtr (MutableByteArray# RealWorld) > > so it does in theory slow down normal ForeignPtrs slightly, but I didn't > measure any difference in the limited tests I did. I vaguely remeber that in the context of the withForeignPtr discussion we where once trying to achieve some similar effect (but couldn't come up with something that would work). Do you remember? Does this, then, effectively solve this old problem? Wouldn't you want newXXX and withXXX variants of the above, too? Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
