Sigbjorn Finne wrote:
Thanks Simon,
great stuff; I like the introduction of these 'native code finalizers',
they've
been sorely missed at times.
You don't say, but will there be a dynamic check to catch such re-entries?
There is (now) a dynamic check, yes.
Cheers,
Simon
__
Johan Tibell wrote:
On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow wrote:
By popular demand, GHC 6.10.2 will support finalizers that are actually
guaranteed to run, and run promptly. There aren't any API changes: this
happens for finalizers created using newForeignPtr as normal.
Does this eff
Thanks Simon,
great stuff; I like the introduction of these 'native code finalizers',
they've
been sorely missed at times.
You don't say, but will there be a dynamic check to catch such re-entries?
--sigbjorn
On 1/14/2009 04:14, Simon Marlow wrote:
By popular demand, GHC 6.10.2 will support
On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow wrote:
> By popular demand, GHC 6.10.2 will support finalizers that are actually
> guaranteed to run, and run promptly. There aren't any API changes: this
> happens for finalizers created using newForeignPtr as normal.
Does this effect GC performance
By popular demand, GHC 6.10.2 will support finalizers that are actually
guaranteed to run, and run promptly. There aren't any API changes: this
happens for finalizers created using newForeignPtr as normal.
However, there's a catch. Previously it was possible to call back into
Haskell from a
