On Fri, 10 May 2024 09:30:03 +0100 Simon McVittie <s...@debian.org> wrote: > 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.
What about OMP_NUM_THREADS environment variable set to 1 in the totem thumbnailer? As in https://salsa.debian.org/gnome-team/totem/-/merge_requests/8 > > 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. Agreed but we are only applying this environment variable to the totem thumbnailer code and this totem thumbnailer children. So I believe it is OK. Also the amount of memory that openblas pthread upping its memory requirement depending on the number of cores can take at max cannot be predicted (if say one run on a Ampere ARM box and has 128 cores). So we cannot predict a hard max limit to the amount that the totem thumbnailer can hardcode as it currently does. Except if we also hardcode the number of threads that openblas pthread can use. Cheers, Alban
