Lennart Augustsson wrote:
Finalizers without guarantees, like what ghc implements, are totally
useless. Since there is no guarantee that the finalizer will ever run
attaching one is a no-op. It has bitten me several times. I wish ghc
implemented finalizers according to the ffi spec.
We do
The way to use finalizers is in conjunction with an exception handler that
provides an absolute guarantee that the resource will be reclaimed on exit.
Note that Java doesn't guarantee to run finalizers on exit either:
Hello Simon,
Monday, December 8, 2008, 2:53:01 PM, you wrote:
just a detached look: may be provide Haskell finalizers with the same
(lack of) warranties?
The way to use finalizers is in conjunction with an exception handler that
provides an absolute guarantee that the resource will be
On Thu, Dec 04, 2008 at 09:09:06AM +, Simon Marlow wrote:
So now I have a scheme whereby I attach a finalizer to a proxy thunk.
data TimeStamp = TimeStamp TS
data TS = TS {
tsWord :: TVar Word64,
tsPrev :: TVar TS,
tsNext :: TVar TS
}
so, the finalizer attached to
Adding finalizers to arbitrary objects was useful for the memo table
application we had in mind when weak pointers were introduced, but for all
the other applications I've come across since then, we really want to add
finalizers to objects whose lifetimes are under programmer control. Notice
Well, the actual problem I am trying to solve involves properly
reclaiming elements in a circularly linked list (next and prev pointers
are TVars). I have a linked list and I need to be able to remove values
from the list when all references to the node no longer exist, not
counting the linked
basically, what would be really nice is if there were something like
registerCommitIO :: IO () - STM ()
where all IO actions registered with this function (within an atomically
block) are executed exactly once if and only if the atomically block
commits. The IO action is not run within
John Meacham wrote:
Are there any caveats to using weak pointers and STM together? in
particular, the two cases I am interested in are
1. is using 'deRefWeak' fully safe inside 'unsafeIOtoSTM'? As in, will
it combine arbitrary STM actions with checking if a weak pointer is
still valid
Are there any caveats to using weak pointers and STM together? in
particular, the two cases I am interested in are
1. is using 'deRefWeak' fully safe inside 'unsafeIOtoSTM'? As in, will
it combine arbitrary STM actions with checking if a weak pointer is
still valid atomically?
2. is using
