On Sat, 2012-03-24 at 18:19 -0400, Paul Davis wrote:
On Sat, Mar 24, 2012 at 4:58 PM, Aurélien Leblond
<blablack(a)gmail.com> wrote:
(by the way you are completely right, I'm
learning audio dev as I go
in this project! that does explain my confusions sometimes...)
not just audio development.
it is slowly becoming more and more true that applications with
attempt to interact with the windowing system from anything other than
"the main GUI thread" (variously defined, depending on the windowing
system) will likely have issues. this is particularly true on windows,
but is becoming more true on X11 systems and even on OS X, its very
important to use an very particular API.
so "create a thread that polls for mouse position" is a no-no, whether
your app is an audio app or not.
"Shared data plus locking" is a pretty crap model in general, really.
When people talk about all the complications that threads introduce,
they're really talking about this. Shared mutable state is the cancer
of multi-threaded programming.
Eventually, we (as in, the software world) are going to have to move to
more appropriate models if we want to be able to feasibly produce
software for increasingly parallel machines.
(Drawing to a screen isn't something you gain anything by making
parallel anyway, I submit that this isn't a flaw of windowing toolkits
but something you just shouldn't be doing anyway)
-dr