Opened 5 years ago

Closed 5 years ago

#3387 closed bug (invalid)

Provide a CInt instance for unboxed arrays

Reported by: tibbe Owned by:
Priority: normal Milestone:
Component: libraries/base Version: 6.10.4
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

Would it make sense to provide a CInt (and perhaps CLong, etc.) instance for unboxed arrays? I missed that a couple of times when storing e.g. file descriptors in an array.

Change History (4)

comment:1 Changed 5 years ago by simonmar

  • Difficulty set to Unknown

Is StorableArray? not suitable?

comment:2 Changed 5 years ago by tibbe

The StorableArray documentation reads:

"It is similar to Data.Array.IO.IOUArray but slower. Its advantage is that it's compatible with C."

Is this still true? Also, are StorableArrays always allocated on the C heap and if so isn't that potentially bad for the GC as it knows nothing about their size?

comment:3 Changed 5 years ago by simonmar

As we discussed on IRC, I'm not sure the comment about the speed of StorableArray? is still true. It probably dates from before we optimised the representation of ForeignPtr.

A StorableArray allocated using newArray is on the Haskell heap, and GC'd as usual. However, you can also make a StorableArray using unsafeForeignPtrToStorableArray, in which case the memory can reside anywhere you like (but presumably the ForeignPtr has a finalizer to deallocate it).

Can I close this ticket?

comment:4 Changed 5 years ago by tibbe

  • Resolution set to invalid
  • Status changed from new to closed

Thanks for the explanation. Closed.

Note: See TracTickets for help on using tickets.