设置

我最近实现了基于mmap的文件读取,并直接遇到了奇怪的行为。相关代码为:

-- | map whole aedat file into memory and return it as a vector of events
-- TODO what are the finalizing semantics of this?
mmapAERData :: S.Storable a => FilePath -> IO (S.Vector (AER.Event a))
mmapAERData name = do
    -- mmap file into memory and find the offset behind the header
    bs <- dropHeader <$> mmapFileByteString name Nothing
    -- some conversion is necessary to get the 'ForeignPtr' from
    -- a 'ByteString'
    B.unsafeUseAsCString bs $ \ptr -> do
      fptr <- newForeignPtr_ ptr
      let count = B.length bs `div` 8 -- sizeof one event
      return $ S.unsafeFromForeignPtr0 (castForeignPtr fptr) count


→ code in context

一些解释:AEDat格式基本上是两个Word32的一长串。一个编码地址,另一个编码时间戳。在此之前,我在dropHeader函数中放入了几行标题文本。如果绝对必要,我可以直接在ForeignPtr上执行此操作,但是我更喜欢使用对ByteStrings起作用的通用函数。

可以在herehere中找到Storable实例。我不确定这里的对齐方式,但是我怀疑对齐8应该是正确的。

问题

读取数据效果很好,但是一段时间后,内存似乎以某种方式被损坏:

>>> es <- DVS.mmapDVSData "dataset.aedat"
>>> es S.! 1000
Event {address = Address {polarity = D, posX = 6, posY = 50}, timestamp = 74.771407s}
>>> :type es
es :: S.Vector (DVS.Event DVS.Address)
>>> _ <- evaluate (V.convert es :: V.Vector (DVS.Event DVS.Address))
>>> es S.! 1000
Event {address = Address {polarity = D, posX = 0, posY = 44}, timestamp = 0s}


显然访问es的所有元素都会以某种方式破坏我的记忆。还是垃圾回收器回收了它?无论哪种方式,这都很奇怪。我该怎么办?

最佳答案

mmapFileByteString执行一个mmap,该ForeignPtr创建一个ForeignPtr,并将该ByteString粘贴到unsafeUseAsCString中。 ForeignPtrPtr强制转换为ForeignPtr,然后从中创建一个新的ForeignPtr。然后,使用第二个S.unsafeFromForeignPtr0并将其与ForeignPtr一起使用以创建向量。

有两个ByteString指向相同的内存是不行的。 GHC运行时将它们视为两个单独的对象。在所有对ForeignPtr的引用均消失之后,将调用其mmap的终结器,从而释放ForeignPtr并回收基础内存。这使第二个Data.ByteString.Internal.toForeignPtr指向无效区域。

解决方案是使用ForeignPtrByteString提取并重新使用unsafeUseAsCString。替换ByteString块与此:

let (fptr,offset,len) = Data.ByteString.Internal.toForeignPtr bs
-- it might be worthwhile to assert that offset == 0
let count = len `div` 8
return $ S.unsafeFromForeignPtr0 (castForeignPtr fptr) count


恕我直言,真正的解决方案是根本不弄乱所有这些东西。通常,只是将文件读入Event,从中取出8字节的子字符串,然后将其手动转换为mmap。所有这些ForeignPtr和都是危险的,并没有比安全正确地执行操作快很多。如果您想要绝对最快的性能而不考虑安全性,请使用C编程。

08-26 15:10