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
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
