To clarify some of the points in this discussion:
Alastair is right in that the finalizer thread isn't necessarily run to
completion if the main thread exits. GHC does run any outstanding
finalizers at the end of the program, but it doesn't necessarily
complete any existing finalizer threads that
> AFAIK this creates some dynamic machine code in malloce'd area, so there
> is need to free it afterward with freeHaskellFunPtr. Are you doing that?
> How? And when? I did not find any suitable place in my code to call
> freeHaskellFunPtr.
Machine code is dynamically created when you turn a Hask
Arjan van IJzendoorn wrote:
>
> foreign import ccall "..." finaliserCreator :: IO (FunPtr (Ptr a ->
IO ()))
>
> and then
>
> finaliser <- finaliserCreator
>
AFAIK this creates some dynamic machine code in malloce'd area, so there
is need to free it afterward with freeHaskellFunPtr. Are you doin
Niklas Sorensson wrote:
Arjan van IJzendoorn wrote:
> I couldn't get finalisers to work either with the newForeignPtr from
> this module. I didn't know how to create a proper FunPtr. In
> Foreign.Concurrent there is a newForeignPtr that is easier to use:
> [deleted]
I seem to remeber running in t
Krasimir Angelov wrote:
The problem here is that the external functions
(instances of type FunPtr) are always executed with
ccall convention regardless of stdcall declaration in
the foreign import. The workaround is to write simple
stub function in C with ccall convention.
You are right, I did not
>
>
> Arjan van IJzendoorn wrote:
> > I couldn't get finalisers to work either with the newForeignPtr from
> > this module. I didn't know how to create a proper FunPtr. In
> > Foreign.Concurrent there is a newForeignPtr that is easier to use:
> > [deleted]
I seem to remeber running in to this
--- Gracjan Polak <[EMAIL PROTECTED]>
wrote:
> foreign import stdcall "windows.h &UnmapViewOfFile"
>funptrUnmapViewOfFile :: FunPtr (Ptr
> a -> IO ())
>
>
> Basically I'd love to do (in Windows world):
>
> mapTheFileToMemory = do
> handle <- winOpenFile(...)
> mapping <
On 10-jun-04, at 17:33, Gracjan Polak wrote:
foreign import stdcall "windows.h &UnmapViewOfFile"
funptrUnmapViewOfFile :: FunPtr (Ptr a -> IO ())
[...]
finview <- newForeignPtr funptrUnmapViewOfFile view
return finview
Strangely enough my finalizer run always this time, no need
On Thursday 10 June 2004 12:07, MR K P SCHUPKE wrote:
> I don't see why GHC can't have a 'callAllOutstandingFinalizers' call
> as part of _exit() or something...
You can do that if your finalizers are written in C (and don't call back into
Haskell) but if they are written in Haskell then you pote
> BUT: This can make some people unhappy. Isn't there a more deterministic
> way to schedule finalizers?
I wrote the Hugs version which does try to be more deterministic so I'm
probably not the best qualified to write about what's wrong with GHC :-)
But, I think part of the problem is that GHC
Alastair Reid wrote:
import Foreign.ForeignPtr
I couldn't get finalisers to work either with the newForeignPtr from
this module. I didn't know how to create a proper FunPtr.
You create a FunPtr using foreign import:
foreign import ccall "malloc.h &free" free_ptr :: FunPtr (Ptr a -> IO ())
forei
I don't see why GHC can't have a 'callAllOutstandingFinalizers' call
as part of _exit() or something...
Keean.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Alastair Reid wrote:
You could give the finalizer thread a chance to run by calling
Control.Concurrent.yield before exiting:
Thanks, it worked. This is ok for me, because my finalizer only closes
some handles. Those are closed at program end anyway, so in this case I
can live with it.
BUT: Th
> [program deleted]
>
> So, this basically means that my finalizer did not get run :(
> [...]
> It should run, in separate thread or not, it doesn't matter here.
>
> Any ideas why doesn't it work?
Hopefully the GHC folk will correct me if I'm wrong but I think what happens
is:
- you allocate obj
For a finalizer to run - the program must be around long
enough for GC to happen. I think your program just exits
and deallocates everything, without any GC.
Keean.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/l
Arjan van IJzendoorn wrote:
> I couldn't get finalisers to work either with the newForeignPtr from
> this module. I didn't know how to create a proper FunPtr. In
> Foreign.Concurrent there is a newForeignPtr that is easier to use:
> [deleted]
So here is the new code:
{-# OPTIONS -fglasgow-exts #-}
> > import Foreign.ForeignPtr
>
> I couldn't get finalisers to work either with the newForeignPtr from
> this module. I didn't know how to create a proper FunPtr.
You create a FunPtr using foreign import:
foreign import ccall "malloc.h &free" free_ptr :: FunPtr (Ptr a -> IO ())
> In Foreign.C
HI Gracjan,
I would like to attach finalizer (written in Haskell) to some pointer.
When the pointer won't be needed any more, finalizer should run. So
here is the code:
import Foreign.ForeignPtr
I couldn't get finalisers to work either with the newForeignPtr from
this module. I didn't know how
18 matches
Mail list logo
