On Fri, 10 May 2024 at 06:14:46 +0200, Alban Browaeys wrote:
> Would adding openblas_set_num_threads(1) to totem-resource.c be fine?
> Wouldn't it add a hard dependency to openblas on totem?
I think this would not be OK. totem cannot assume that the current
implementation of libblas.so.3 or liblapack.so.3 is openblas: it might
equally well be libatlas3-base, which presumably does not offer that
openblas-specific function.
> Should the ffmpeg or gstreamer provide an API to set this openblas
> number or thread to 1 in case the application is multi-threaded (I
> believe totem is multi-threaded) to avoid adding such hard dependency
> in the upper layers if they don't already provides such an API?
My understanding is that all GStreamer programs are automatically
multi-threaded, because GStreamer uses threads for the elements of a
pipeline.
It is not usually safe for libraries to alter process-global state at
runtime, because by the time the application calls into the library,
it might already have multiple threads running.
> until a solutoin that does not involve hardcoding low level optional
> dependencies into totem is sorted out (probably more of an upsteam
> issue), one can add "OPENBLAS_NUM_THREADS=1" to the environment of the
> totem thumbnailer.
It would be possible for affected applications like totem to work
around this bug by adding g_setenv("OPENBLAS_NUM_THREADS", "1", TRUE)
near the beginning of main(), before they have had the opportunity to
create multiple threads.
After a second thread has been created, it is no longer safe to call
g_setenv() or similar functions like setenv() and putenv(), so it really
does have to be right at the beginning of main(), and probably cannot
be in library code.
This seems like a workaround that would not scale particularly well,
because totem is far from being the only application that uses GStreamer.
smcv
