[darcs-users] darcs patch: switch Darcs.Patch.FileName to be ByteString.Char8 int...

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Mon Sep 28 09:44:42 UTC 2009

On Mon, 2009-09-28 at 09:06 +0100, Simon Marlow wrote:

> > It's a medium term project. There is no short term fix. The problem is
> > using pinned heap arrays. Switching to unpinned would entail an almost
> > complete rewrite of the bytestring implementation. That is something I
> > would like to do however it's not quick, and it would have to pass the
> > "dons" test, that the results are absolutely definitely as good as the
> > current version. Don is understandably nervous about upsetting the
> > existing mature implementation. That would also include the ability to
> > mmap, which would be lost under a straightforward re-implementation to
> > use unpinned arrays. Handling mmap'ed ByteArray# is another
> > mini-project.
> As a workaround, would it be possible to provide an unsafePack that 
> gives you an unpinned ByteString, with the onus on the caller to ensure 
> they never pass it to C?  Perhaps it would even be possible to check 
> that it was never passed to C?  And it's only "safe" foreign imports 
> that are dangerous, it's fine to pass an unpinned ByteArray to an unsafe 
> foreign import (though that's probably not something we should rely too 
> heavily on, in case we want to change it in the future).

I don't think it's possible while using a ForeignPtr representation. If
we make the ByteArray inside the ForeignPtr unpinned then the Addr# is
not guaranteed to be kept in sync. There are no points where we could
keep it in sync since we do extract the Ptr from the ForeignPtr using
withForeignPtr, but the ByteArray# could be moved by the GC while we're
doing the withForeignPtr action.

As far as I can see the only way to do it is by changing the
representation to be a ByteArray#:

data ByteString = ByteString ByteArray# Int Int


More information about the darcs-users mailing list