Rather go to https://github.com/galfar/imaginglib/discussions
Posted by Galfar
- 10 November 2017, 00:58:54Hi,
yes the library is not really thread safe -
most of the library core is from 2003 & 2004 with no thread safety in mind.
Of course, it's been sitting in my todo list for a long time now.
There are several suspect places mostly related to image loading and saving,
rest of the library should be quite ok.
What I'm mostly worried about is that used 3rd party libs like OpenJpeg and libtiff
would cause problems.
Anyway, improvements to thread safety are planned but that "time for the library" is still very limited :(
yes the library is not really thread safe -
most of the library core is from 2003 & 2004 with no thread safety in mind.
Of course, it's been sitting in my todo list for a long time now.
There are several suspect places mostly related to image loading and saving,
rest of the library should be quite ok.
What I'm mostly worried about is that used 3rd party libs like OpenJpeg and libtiff
would cause problems.
Anyway, improvements to thread safety are planned but that "time for the library" is still very limited :(
Posted by Hugie
- 8 November 2017, 13:51:46Hi Galfar,
about a year ago, we detected that the library seems not to be thread safe.
We had 2 threads decoding hundreds of jpegs in a row, which always resulted in unpredictable crashes.
We found some code positions, where global variables were used, which caused the crash.
We fixed it by serializing the decoding calls.
There were some plans in testing the introduction of threadvars for these variables, but since the bug was solved, there was no need from "above" for this anymore ;)
Sadly, i lost the documentation of the code positions which caused this.
In general, are their any plans to make the library thread safe by yourself?
I am asking now, since you seem to have time for this awesome library again ;)
about a year ago, we detected that the library seems not to be thread safe.
We had 2 threads decoding hundreds of jpegs in a row, which always resulted in unpredictable crashes.
We found some code positions, where global variables were used, which caused the crash.
We fixed it by serializing the decoding calls.
There were some plans in testing the introduction of threadvars for these variables, but since the bug was solved, there was no need from "above" for this anymore ;)
Sadly, i lost the documentation of the code positions which caused this.
In general, are their any plans to make the library thread safe by yourself?
I am asking now, since you seem to have time for this awesome library again ;)
SMF spam blocked by CleanTalk