Hi,
I get at least four threads
Just for some context: here on Windows I get 10 threads when I open Pd and start DSP, but only 2 of these are active and the remaining 8 or idle.
The Pd core itself does not spawn any threads, only the audio backend and certain objects/externals do (notably [readsf~] and [writesf~]).
But why do you care about the number of threads in the first place?
As an aside: is the code in z_ringbuffer.{c,h} considered trustworthy? I note that the other code in PD appears to use the sys_ringbuffer* API, which seems to be built on the PA ringbuffer.
Is the PA ringbuffer considered trustworthy? Note that the ringbuffer code in "s_audio_ringbuf.c" - for whatever reason - is missing all the memory barriers from the original PA implementation. This happens to work as the implementation is in another source file and (non-inline) function calls act as compiler barriers and Intel has a strong memory model, but if compiled with LTO this code may very well fail on other platforms, particularly on ARM.
I ask because I had some problems with z_ringbuffer.c and after a code read, there are some bits which look sketchy enough to me that I decided to stop using it.
Which problems did you have? And which bits look sketchy? There are some things that could be improved. The original code has been written before C11, i.e. before C/C++ got an official memory model. As a consequence, the platform specific atomic instructions / memory barriers are stronger than required. In general, SYNC_FETCH should really be called SYNC_LOAD and SYNC_COMPARE_AND_SWAP should be called SYNC_STORE. With C11, SYNC_LOAD could be just an atomic_load (with memory_order_acquire) and SYNC_STORE could be an atomic_store (with memory_order_release). Apart from that, the code looks fine to me.
Christof
On 11.04.2024 05:19, Caoimhe &co wrote:
Hi y'all -
I'm about hip deep in what is probably an ill-advised project,and I have run into a situation where I am genuinely stumped. I am running a build of PD 0.53.1 and I notice that regardless of the audio back end I choose (between OSS, ALSA, and JACK, anyway) that I get at least four threads (more with JACK, but that may be my own fault) running PD on the latest AVLinux (based on MX, which is based on AntiX, which is based on Debian).
What's up with that? What are those four threads all doing? I ask because I have only found the pthread_create that are in d_soundfile.c (reasonable) and d_fft_fftsq.c; and it certainly seems like none of those should be active just from starting up PD without even starting up the DSP loop.
As an aside: is the code in z_ringbuffer.{c,h} considered trustworthy? I note that the other code in PD appears to use the sys_ringbuffer* API, which seems to be built on the PA ringbuffer. I ask because I had some problems with z_ringbuffer.c and after a code read, there are some bits which look sketchy enough to me that I decided to stop using it.
d/c/&cet
GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev