So plugins can be kind-of malicious with the host's thread pool. I guess that getting the thread info before running a task and restoring it afterwards might be necessary for hosts. This provided that the non-modified thread properties case is very cheap (info on thread local storage, no syscall made if no changes) and only plugins doing wrong pay for it.
Using Multiple Threads In Audio Thread
-
- KVRian
- 914 posts since 4 Jan, 2007
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
Why would you possibly want to mess with the host threads from the plugin though? You can already do this kind of stuff with the regular host threads in any plugin if you absolutely want to, but it just doesn't make any sense whatsoever.
edit: My point wasn't that plugins can mess with the host threads, but rather that the actual thread creation method doesn't make a whole lot of difference in practice.
- u-he
- 28044 posts since 8 Aug, 2002 from Berlin
Yes we do, something about Quality of Service, but that's beyond my knowledge of the topic.
-
- KVRAF
- 2393 posts since 28 Mar, 2005
Alright. Because it probably plays a bit in the benchmark as well.
-
- KVRian
- 914 posts since 4 Jan, 2007
I wouldn't either. But who knows what people might be able to come with, which bugs can happen, etc. Probably I'm too paranoid.mystran wrote: ↑Tue Dec 14, 2021 4:03 pm Why would you possibly want to mess with the host threads from the plugin though? You can already do this kind of stuff with the regular host threads in any plugin if you absolutely want to, but it just doesn't make any sense whatsoever.
edit: My point wasn't that plugins can mess with the host threads, but rather that the actual thread creation method doesn't make a whole lot of difference in practice.
My point was unrelated to the thread creation method. Your comment just reminded me that fact.
- KVRist
- Topic Starter
- 77 posts since 8 Nov, 2020
How can sharing threads across multiple plugin instances be done? Wouldn’t there be security measures to prevent that?mystran wrote: ↑Sat Oct 16, 2021 5:10 pm Launching new threads in audio code is not a good idea, but you can use a threadpool just fine (eg. I do all the time). Basically when the plugin DLL is loaded, I fire up one thread per CPU and bump them up to real-time priority. Then they wait on a queue. Then when I have something that can be done by a worker thread, I put that work (eg. one job for each voice) into the queue. Then wait for all the jobs to finish. Multiple instances of the same plugin can share the same threadpool.
It's a good idea to check the blocksize and process very short blocks directly (eg. some hosts sometimes pass the occasional single-sample block even if the average is much longer) to avoid threading when the sync overhead would be higher than the processing cost, but other than that it "just works" except for the slightly unfortunate situation of not being able to share the same worker threads between multiple plugins and the host.
- KVRAF
- 7868 posts since 12 Feb, 2006 from Helsinki, Finland
What I wrote above assumes all the instances run in the same process. Usually this is the case. When they are in the same process, it's a matter of sharing a pointer and there are no security measures against passing around pointers within a single process. The canonical solution is to make the pool itself a singleton (eg. created first time it's requested).