On Wednesday 07 Jan 2004 11:43 am, Simon Marlow wrote:
> > Hmm, further experiments with creating zillions of garbage
> > ForeignPtrs (not just 1) reveals that the problem only occurs
> > if *no* garbage collection has occured before the program shuts
> > down. In other words, as long as at least o
> Hmm, further experiments with creating zillions of garbage
> ForeignPtrs (not just 1) reveals that the problem only occurs
> if *no* garbage collection has occured before the program shuts
> down. In other words, as long as at least one garbage collection
> has occured, it doesn't matter if lib
> The other thing that strikes me about this is don't we also have
> the same potential problem with weak pointer finalisers? Can they
> be supported in Haskell without pre-emptive concurrency?
Weak pointers are a GHC-only extension too, at the moment. They require
some careful GC algorithms as
Hello,
Thanks for that explanation, I see the problem now.
Though to be honest, I'm not convinced that the situation
for Haskell implementations which don't implement pre-emptive
concurrency need be as bad as you suggest. But that's probably
presumptious of me seeing as I know little about the
im
On Monday 05 Jan 2004 3:14 pm, Simon Marlow wrote:
> > The other complication I can see is that ForeignPtr finalisers can't
> > be Haskell. So I have to call the Haskell finalisation from C.
> > Is that safe? I'm afraid I still don't fully understand why Haskell
> > finalisers are unsafe or why (if
> > I'm afraid I still don't fully understand why Haskell
> > finalisers are unsafe or why (if) calling Haskell from a C finaliser
> > (which then called C land again) would be any safer.
The FFI standard doesn't say that calling C finalizers is unsafe (which would
imply that the finalizers pote
> The other complication I can see is that ForeignPtr finalisers can't
> be Haskell. So I have to call the Haskell finalisation from C.
> Is that safe? I'm afraid I still don't fully understand why Haskell
> finalisers are unsafe or why (if) calling Haskell from a C finaliser
> (which then called C
On Wednesday 31 Dec 2003 10:05 am, Adrian Hey wrote:
> On Wednesday 31 Dec 2003 8:56 am, Adrian Hey wrote:
> > Intended use is something like this...
> >
> > {-# notInline libXYZRef #-}
> > libXYZRef :: LibRef
> > libXYZRef = unsafePerformIO newLibRef
> >
> > main :: IO ()
> > main = finally (initL
On Wednesday 31 Dec 2003 8:56 am, Adrian Hey wrote:
> Intended use is something like this...
>
> {-# notInline libXYZRef #-}
> libXYZRef :: LibRef
> libXYZRef = unsafePerformIO newLibRef
>
> main :: IO ()
> main = finally (initLibXYZ >> userMain) (killLibRef libXYZRef
> shutDownLibXYZ)
> -- initLi
On Wednesday 31 Dec 2003 8:56 am, Adrian Hey wrote:
> The problem is I get a "fail: <>" error if no garbage collection
> has occured when killLibRef is called (I.E. killLibRef saves shutDownLibXYZ
> for later use because the reference count is non-zero).
Sorry, I should clarify this. The error doe
Hello again,
I've tried the simplest possible reference counting approach which should
be OK if all finalisers are run eventually (as I think is the case currently
with ghc 6.2).
But I don't seem to be able to get it to work. I've attached the library
reference counting code (LibRef module) to th
On Tuesday 23 Dec 2003 7:22 am, Adrian Hey wrote:
> Assuming the weak pointers solution is the way to go, I've been
> re-aquainting myself with System.Mem.Weak and now I'm now wondering
> what is an appropriate key for each ForeignPtr.
>
> Would it be OK to use the ForeignPtr itself as it's own key
Hello
On Tuesday 23 Dec 2003 9:27 am, Simon Marlow wrote:
> > Assuming the weak pointers solution is the way to go, I've been
> > re-aquainting myself with System.Mem.Weak and now I'm now wondering
> > what is an appropriate key for each ForeignPtr.
>
> Before we go down that route, I want to be s
> Assuming the weak pointers solution is the way to go, I've been
> re-aquainting myself with System.Mem.Weak and now I'm now wondering
> what is an appropriate key for each ForeignPtr.
Before we go down that route, I want to be sure that it's actually
necessary to use weak pointers. It sounds li
On Monday 22 Dec 2003 8:53 pm, Carl Witty wrote:
> > > Thanks for your reply. I'm afraid it's left me even
> > >
> > > more confused about which way to go with this :-(
>
> Is your problem something you could handle with a C atexit() handler?
That's a good idea. With ghc I guess this will work, a
On Monday 22 Dec 2003 10:13 am, Simon Marlow wrote:
> > Thanks for your reply. I'm afraid it's left me even
> > more confused about which way to go with this :-(
> >
> > If it's possible that future Haskell FFI's don't guarantee
> > that all finalisers are run then this more or less rules
> > out t
> > Thanks for your reply. I'm afraid it's left me even
> > more confused about which way to go with this :-(
Is your problem something you could handle with a C atexit() handler?
Carl Witty
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
ht
On Mon, Dec 22, 2003 at 11:34:14AM +0100, Tomasz Zielonka wrote:
>
> Moreover, it is not guaranteed that performGC will trigger a full GC.
> Most often it will reclaim only the 0th generation. I think it would be
> useful to have something like performFullGC.
Or rather performMajorGC :)
It seems
On Mon, Dec 22, 2003 at 10:13:42AM -, Simon Marlow wrote:
>
> performGC doesn't do anything that you can rely on :-) In practice, it
> probably starts all the finalizers that are ready to run, but it
> certainly doesn't wait for their termination.
Moreover, it is not guaranteed that perform
> Thanks for your reply. I'm afraid it's left me even
> more confused about which way to go with this :-(
>
> If it's possible that future Haskell FFI's don't guarantee
> that all finalisers are run then this more or less rules
> out the use of the reference counting solution (which
> wasn't par
Thanks for your reply. I'm afraid it's left me even
more confused about which way to go with this :-(
If it's possible that future Haskell FFI's don't guarantee
that all finalisers are run then this more or less rules
out the use of the reference counting solution (which
wasn't particularly attrac
> I hope this question isn't too stupid, but I can't find
> any obvious way to do this from reading the ghc docs.
>
> What I want to do is call a final foreign function (a
> library shutdown routine) when Haskell terminates, but
> after all ForeignPtr finalisers have been run.
>
> I suppose I co
Hello,
I hope this question isn't too stupid, but I can't find
any obvious way to do this from reading the ghc docs.
What I want to do is call a final foreign function (a
library shutdown routine) when Haskell terminates, but
after all ForeignPtr finalisers have been run.
I suppose I could imple
23 matches
Mail list logo
