Summary: | Clean up m_processLock logic in AudioBasicProcessorNode and AudioGainNode | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Raymond <rgbbones> | ||||||
Component: | Web Audio | Assignee: | Raymond <rgbbones> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | crogers, kbr, webkit.review.bot | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Raymond
2012-01-20 23:07:25 PST
Created attachment 123435 [details]
Patch
Comment on attachment 123435 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=123435&action=review > Source/WebCore/webaudio/AudioBasicProcessorNode.cpp:-128 > - // We need to be careful since we may be actively processing right now, so synchronize with process(). > - MutexLocker locker(m_processLock); In AudioGainNode, all m_processLock related code is removed since no one use it anymore. While for AudioBasicProcessorNode, only remove the lock here, while reserve the lock mechanism in process(), since subclass might do some thing in main thread. ( Though, actually it seems to me they do not at present.) (In reply to comment #2) > (From update of attachment 123435 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=123435&action=review > > > Source/WebCore/webaudio/AudioBasicProcessorNode.cpp:-128 > > - // We need to be careful since we may be actively processing right now, so synchronize with process(). > > - MutexLocker locker(m_processLock); > > In AudioGainNode, all m_processLock related code is removed since no one use it anymore. While for AudioBasicProcessorNode, only remove the lock here, while reserve the lock mechanism in process(), since subclass might do some thing in main thread. ( Though, actually it seems to me they do not at present.) Raymond, thanks for the patch. I think we should remove the lock in AudioBasicProcessorNode::process() as well. m_processLock is private, so no sub-class can do anything with it. Also, all changes should now happen with the AudioContext lock in the pre or post-render tasks anyway so we shouldn't need it. Does that make sense? Created attachment 124481 [details]
Patch
Thanks Raymond, looks good. Comment on attachment 124481 [details]
Patch
rs=me
Comment on attachment 124481 [details] Patch Clearing flags on attachment: 124481 Committed r106420: <http://trac.webkit.org/changeset/106420> All reviewed patches have been landed. Closing bug. |