base-4.10.0.0: Basic libraries

Copyright(c) The University of Glasgow 2003
LicenseBSD-style (see the file libraries/base/LICENSE)
Maintainerffi@haskell.org
Stabilityprovisional
Portabilitynon-portable (requires concurrency)
Safe HaskellTrustworthy
LanguageHaskell2010

Foreign.Concurrent (signature[?])

Contents

Description

FFI datatypes and operations that use or require concurrency (GHC only).

Synopsis

Concurrency-based ForeignPtr operations

These functions generalize their namesakes in the portable Foreign.ForeignPtr module by allowing arbitrary IO actions as finalizers. These finalizers necessarily run in a separate thread, cf. Destructors, Finalizers and Synchronization, by Hans Boehm, POPL, 2003.

newForeignPtr :: Ptr a -> IO () -> IO (ForeignPtr a) Source #

Turns a plain memory reference into a foreign object by associating a finalizer - given by the monadic operation - with the reference. The storage manager will start the finalizer, in a separate thread, some time after the last reference to the ForeignPtr is dropped. There is no guarantee of promptness, and in fact there is no guarantee that the finalizer will eventually run at all.

Note that references from a finalizer do not necessarily prevent another object from being finalized. If A's finalizer refers to B (perhaps using touchForeignPtr, then the only guarantee is that B's finalizer will never be started before A's. If both A and B are unreachable, then both finalizers will start together. See touchForeignPtr for more on finalizer ordering.

addForeignPtrFinalizer :: ForeignPtr a -> IO () -> IO () Source #

This function adds a finalizer to the given ForeignPtr. The finalizer will run before all other finalizers for the same object which have already been registered.

This is a variant of Foreign.ForeignPtr.addForeignPtrFinalizer, where the finalizer is an arbitrary IO action. When it is invoked, the finalizer will run in a new thread.

NB. Be very careful with these finalizers. One common trap is that if a finalizer references another finalized value, it does not prevent that value from being finalized. In particular, Handles are finalized objects, so a finalizer should not refer to a Handle (including stdout, stdin or stderr).