Closed nh2 closed 5 years ago
I believe I wrote that comment based on the C++ implementation. Upon closer inspection I believe it is actually thread safe.
Internally it uses some ImageEncoder
, which is a Ptr<BaseImageEncoder>
. It changes some properties of this encoder object when you invoke imencode
. But it does so on a copy of the original object. I think I missed the copy part when I wrote the comment stating it is not thread safe.
Did you look into using valgrind suppression files for opencv?
https://github.com/opencv/opencv/tree/master/platforms/scripts
Thanks for the explanations. If the function is actually thread safe, we probably want to remove the comment.
Did you look into using valgrind suppression files for opencv?
No, so far I haven't needed to reduce the number of messages emitted.
By now I believe my potential memory leak doesn't exist and it's simply a reference I hold from Haskell (my ForeignPtr
with finalizer hasn't been GC'd yet, I'll retest that with performMajorGC
).
Fixed by 28b22ed35f793cf62d938545f9f973cca66e6827
For
imencode
, there's this warning:https://github.com/LumiGuide/haskell-opencv/blob/dd51d7cfb1513e03516706465c246164e33fb589/opencv/src/OpenCV/ImgCodecs.hs#L83
Where does the non-thread-safety come from?
I'm investigating a memory leak reported by valgrind and am wondering if this is relevant for it.