[Webkit-unassigned] [Bug 34912] audio engine: add ReverbConvolver class

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=34912





--- Comment #30 from Chris Rogers <crogers at google.com>  2010-03-29 14:24:10 PST ---
Hi Jeremy, hopefully my latest changes address the last of your comments.

> Hmm...so each impulse response has its own background thread?  That seems a bit excessive, but no need to fix now I suppose.

Good observation.  It's actually a good thing if the machine has enough cores
to really get the advantage of the other threads.  On the Mac on Snow Leopard,
it might be possible to take advantage of "Grand Central Dispatch", but
otherwise it would be possible to check the number of cores on the machine and
try to optimally farm out worker threads to best match the number of cores. 
But this is an optimization which isn't critical to the fairly good performance
we're already seeing...

> IIRC, it's better to signal outside of the lock so that it doesn't wake up, try
> to get the lock, and then sleep again.
> Also, use MutextLocker with {}'s to scope it.

I'm pretty sure it has to be signaled inside the lock which is the pattern I've
seen in other code like this, and also seems to be the pattern used elsewhere
in WebKit.

> I'm pretty sure you can simply set the variable to try and send the signal
> (without the try lock here).  As long as the consumer has something that causes
> a read barrier (which I believe the mutex will) you should be OK.  It might be
> a good idea to write a simple app to verify all this threading stuff (whether
> you go with your model or my suggestion) works as expected though.  :-)

I think there are some race conditions which can happen if you don't actually
get the lock here.

> If you do keep this a raw pointer keep it as close as possible to where it gets
> assigned to an OwnPtr.
> And, not to beat a dead horse, but did you try making this an OwnPtr and then
> call .release() on that when passing it to the array?  I think that'd work and
> I think it'd be the best.

Good call - this seems to work and be the best solution...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.