Repository navigation
thread safety #279
Description
Activity
Probably this is only a documentation issue...
Patches welcome.
Oops, just came across this one too from running helgrind on my application.
I completely sympathize having had to convert C code with statics to thread safe code in the past. It is unsatisfying at best. It looks like the safest practice is to place mutex locks around sf_open(). This may also be need in the sf_read() functions in the situation where they hit an error.
The fix I think would be to localize these string buffers to the file handle data structure. I don't quite trust myself enough to do something like that and there may be a reason why you didn't do it in the first place ;).
The fix I think would be to localize these string buffers to the file handle data structure. I don't quite trust myself enough to do something like that and there may be a reason why you didn't do it in the first place ;).
IMHO those static variables for were added to handle errors for open functions.
sf_openreturnsNULLin case of error and we have no idea what was happend,I think we can do it whithout static error variables. Like this:
SNDFILE *sf_open_ex(..., int *error);
or
int sf_open_ex(... , SNDFILE *sndfile);
libsndfile is mostly thread safe. The one exception is these error reporting variables.
In practice having these not be thread safe is not an issue and changing the API just for this is not worth it IMO.
(this was originally reported as https://bugs.debian.org/#761307)
I see you wrote on http://comments.gmane.org/gmane.comp.audio.libsndfile.devel/564
This would be fine, but there are some global/static variables which break thread-safety. So far I found
sf_errno,sf_logbuffer,sf_syserrwhich apparently are used only during opening, includingsf_strerror(NULL)andsf_command(NULL, SFC_GET_LOG_INFO, ...).So I conclude opening even different sound files concurrently is not thread-safe!