Yes my withSomething method are of this kind withGeometry :: Factory -> Geometry -> (Ptr HklGeometry -> IO b) -> IO b withGeometry f g fun = do fptr <- newGeometry f g withForeignPtr fptr fun newGeometry :: Factory -> Geometry -> IO (ForeignPtr HklGeometry) If I come back to my method, at the beginin I had this signature. solveTraj :: Factory -> Geometry -> Detector -> Sample -> [Engine] -> IO [GEometry] the last line was mapM (solve' engine n e >>= getSolution0) [engines] but When I run the code for 100000 points I got a huge consomation of the memory... So I tryed to solve this problem using the Pipe. solveTraj :: Factory -> Geometry -> Detector -> Sample -> Pipe Engine Geometry IO () solveTraj f g d s = do e <- await let name = engineName e withSample s $ \sample -> withDetector d $ \detector -> withGeometry f g $ \geometry -> withEngineList f $ \engines -> withCString name $ \cname -> do c_hkl_engine_list_init engines geometry detector sample engine <- c_hkl_engine_list_engine_get_by_name engines cname nullPtr n <- c_hkl_engine_pseudo_axis_names_get engine >>= darrayStringLen yield $ solve' engine n e >>= getSolution0 Now I think that this is maybe the wrong way to solve my issue. the computation done by my C library in the solve' depends of the previous step. when I solve my system the geometry "C object" move. (this is a side effect really important for my computation) solve' :: Ptr HklEngine -> CSize -> Engine -> IO (ForeignPtr HklGeometryList) solve' engine n (Engine _ ps _) = do let positions = [v | (Parameter _ v _) <- ps] withArray positions $ \values -> c_hkl_engine_pseudo_axis_values_set engine values n unit nullPtr >>= newForeignPtr c_hkl_geometry_list_free so I can not convert this into a single pipe step... or maybe it is possible to create a pipe which store this internal state in order to treat each steps. It start to be a little bit difficult for me to manage all this :)) Cheers Frederic. Ps: the starting point of this is the huge memory use by my software...