[PD-dev] soundfiler~ thread usage

Giulio Moro giuliomoro at yahoo.it
Tue Apr 17 17:34:51 CEST 2018

I would discourage calling pthread_create() when sending an open message. pthread_create() comes with overhead associated with resource allocation, which makes it particularly unsuitable for real-time operation.
The sleeping threads are probably not causing a big performance overhead , however I see how having too many *active* threads at the same time would cause overhead because of the context switching due to the OS's round-robin scheduling. I *think* an improvement could be to have a small pool of threads belonging to all [soundfiler~] objects that you manage internally and allocate to the reading operations according to your priorities, but maybe it's more trouble than it's worth it?

On Monday, 16 April 2018, 02:12:59 BST, Miller Puckette <msp at ucsd.edu> wrote: 

This might be OS-dependent - on linux at least, you can create all the
threads you want and have them sleep forever waiting on a mutex with no
performacne hit (as far as I know anyhow).

I dont know what the ramifications would be of starting up threads only
when a readsfi~ or writesf~ gets an "open" message - I don't think that would
cause problems except for the slight increase in complexity of the code.


On Mon, Apr 16, 2018 at 02:19:55AM +0200, Dan Wilcox wrote:
> I'm working on a project with 64 soundfiler~ objects which may or may not be used all at once. I've noticed in the debugger that the each object is using a thread after instantiation, even when not actually reading a file. Is this normal? If so, what's the reasoning? I'd think it would be better, resource-wise, to spin up a thread as needed. Does starting/joining a thread take too long and break determinacy?
> --------
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>

> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

Pd-dev mailing list
Pd-dev at lists.iem.at

More information about the Pd-dev mailing list