[Haskell-cafe] ForeignPtrs, Finalizers and thread-local storage
paston.cooper at gmail.com
Tue Jul 3 10:58:54 UTC 2018
The Control.Concurrent.bracket solution should involve
Control.Concurrent.runInBoundThread as well.
On 3 July 2018 at 11:10, Justin Paston-Cooper <paston.cooper at gmail.com>
> glpk-hs defines a binding to glpk, a linear programme library. A linear
> programme is created by calling `glp_create_prob` and deleted by calling
> `glp_delete_prob`. These two C functions manage memory themselves using
> thread-local storage.
> They are called by glpk-hs using the foreign function interface in the
> following code. Note that glpDelProb and glpCreateProb are imported foreign
> runGLPK :: GLPK a -> IO a
> runGLPK m = do lp <- newForeignPtr glpDelProb =<< glpCreateProb
> withForeignPtr lp (execGLPK m)
> It seems that sometimes the finaliser is called in a thread different to
> the one where glp_create_prob is called. This leads to glpk aborting with a
> dynamic memory allocation error when tries to de-allocate the linear
> programme in the wrong thread-local storage, which has never seen that
> Given that the ForeignPtr is used only in runGLPK, runGLPK could of course
> be fixed by using Control.Concurrent.bracket instead. However, I'm
> interested to know whether there is a solution to this problem.
> I'm only assuming that the finaliser sometimes runs in a different thread.
> If this is indeed the case, then is there any way to ensure that a
> finaliser runs in the thread where the pointer is created?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe