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/
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.
cheers Miller
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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? Giulio
On Monday, 16 April 2018, 02:12:59 BST, Miller Puckette msp@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.
cheers Miller
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@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
-
Dan Wilcox -
Giulio Moro -
Miller Puckette