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 sure that it's actually necessary to use weak pointers. It sounds like your application has the following properties:
- there is a library that can allocate some resources, where each resource is represented by a ForeignPtr
Basically, but there are also some hardware resources (other than memory) which are claimed just as a result of library initialisation (before any library objects have been created).
- a resource needs to be released when it is no longer referenced
Yes, that's right.
- at some point, we would like to free *all* outstanding resources (either at the end of the program, or when the library is no longer required).
I want to free all heap space used by library objects, then free whatever other hardware resources have been claimed by the library (by calling the appropriate shutdown routine).
If this is the case, I'd do it something like this:
- keep a global list of the pointers still to be released, probably a doubly-linked list. Lock the whole thing with an MVar. Elements are Ptrs, not ForeignPtrs.
- the finaliser on each ForeignPtr removes the corresponding Ptr from the list.
- the final cleanup routine explicitly releases all the remaining Ptrs in the list, holding the MVar lock as it does so to avoid race conditions with finalisers.
Weak pointers aren't required, AFAICT.
Maybe, I'd forgotten that I could get at the Ptr inside each ForeignPtr. I guess I've still got to think about the consequences of ForeignPtr finalisers being run after the "final" shutdown. (Making each List cell an IORef (Maybe something) would do that I think). 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 land again) would be any safer. Thanks for the idea though. I'll play about with a few implementations of these ideas after christmas and see what problems I encounter. Regards -- Adrian Hey