The FFI libraries currently contain support for explicit allocation and deallocation via the malloc/free family and support for implicit allocation and deallocation via alloca and friends. But there is a very useful level between these extremes: Pooled memory management. Under this scheme, (re-)allocations belong to a given pool, and everything in a pool is deallocated when the pool itself is deallocated. You can find the implementation and the (lean) docs at: http://haskell.org/HOpenGL/PoolRFC/Pool.hs http://haskell.org/HOpenGL/PoolRFC/html/Foreign.Marshal.Pool.html I propose adding this module to FFI addendum and the exports of module Foreign.Marshal. Although the module is definitely not a candidate for the next ACM award, it's a useful and common abstraction which can easily be implemented on the existing FFI modules. Comments? Cheers, S.
On 18-Jan-2003, Sven Panne <Sven.Panne@informatik.uni-muenchen.de> wrote:
The FFI libraries currently contain support for explicit allocation and deallocation via the malloc/free family and support for implicit allocation and deallocation via alloca and friends. But there is a very useful level between these extremes: Pooled memory management. Under this scheme, (re-)allocations belong to a given pool, and everything in a pool is deallocated when the pool itself is deallocated.
You can find the implementation and the (lean) docs at:
http://haskell.org/HOpenGL/PoolRFC/Pool.hs http://haskell.org/HOpenGL/PoolRFC/html/Foreign.Marshal.Pool.html
I propose adding this module to FFI addendum and the exports of module Foreign.Marshal. Although the module is definitely not a candidate for the next ACM award, it's a useful and common abstraction which can easily be implemented on the existing FFI modules.
Comments?
In general, I think that support for pooled allocation is a very good idea. With regard to the specific interface proposed here: why is the Pool type polymorphic, and allocation in a pool restricted to only allocating values whose type matches the pool's type parameter? It would be much nicer to support allocating different types in the same pool. The implementation at http://haskell.org/HOpenGL/PoolRFC/Pool.hs has obviously not been adequately tested, since it contains at least one bug: the lines pooledMallocArray0 pool size = pooledMallocArray0 pool (size + 1) ^ | | oops! should be pooledMallocArray0 pool size = pooledMallocArray pool (size + 1) -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson wrote:
[...] why is the Pool type polymorphic, and allocation in a pool restricted to only allocating values whose type matches the pool's type parameter? It would be much nicer to support allocating different types in the same pool.
No deep reason, it was just a remnant of the module's history. I've removed the type parameter from Pool's constructor. The updated module and docs are already uploaded on haskell.org.
The implementation at http://haskell.org/HOpenGL/PoolRFC/Pool.hs has obviously not been adequately tested, [...]
Uh-oh! :-] Fixed. Admittedly, I've only tested the some of the non-array stuff... Thanks for the lightning-fast reply (including the code review!), S.
Sven Panne <Sven.Panne@informatik.uni-muenchen.de> wrote,
The FFI libraries currently contain support for explicit allocation and deallocation via the malloc/free family and support for implicit allocation and deallocation via alloca and friends. But there is a very useful level between these extremes: Pooled memory management. Under this scheme, (re-)allocations belong to a given pool, and everything in a pool is deallocated when the pool itself is deallocated.
To be honest, I am reluctant to add this module to the FFI addendum. This is not to say that the module may not be useful and may not be a worthwhile addition to the library hierachy. Here are my reasons: * I want to get v1.0 of the spec fixed. We are really only in bug fix mode for quite a while and only the finalizer problems held us back from finishing the spec. * I am sure there are plenty more useful FFI-related libraries. However, the initial plan was to define basic functionality on top of which more elaborate schemes can be implemented. We need to draw the line somewhere. In particular, I don't want to add a largely untested library. So, I propose to add Pool to the portable libraries package, but leave it out of the spec. Cheers, Manuel
On 20-Jan-2003, Manuel M T Chakravarty <chak@cse.unsw.edu.au> wrote:
Sven Panne <Sven.Panne@informatik.uni-muenchen.de> wrote,
* I want to get v1.0 of the spec fixed. We are really only in bug fix mode for quite a while and only the finalizer problems held us back from finishing the spec. ... In particular, I don't want to add a largely untested library. ... So, I propose to add Pool to the portable libraries package, but leave it out of the spec.
I agree. I support the inclusion of this proposal in FFI v1.1 or v2.0, but let's ship v1.0 first. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
participants (3)
-
Fergus Henderson -
Manuel M T Chakravarty -
Sven Panne