Introduce a callback queue on a tap #2815
Conversation
Fixes AudioKit#2814, but it feels clumsy as we have two syncronisation mechanisms - locks and queue. We should probably rewrite a tap to work on one dispatch queue and remove all the locks.
![hound[bot]](https://avatars.githubusercontent.com/in/3598?s=60&v=4){kind=small}
| @@ -18,10 +18,10 @@ open class RawDataTap: BaseTap { | |||
| /// - input: Node to analyze | |||
| /// - bufferSize: Size of buffer to analyze | |||
| /// - handler: Callback to call when results are available | |||
| public init(_ input: Node, bufferSize: UInt32 = 1_024, handler: @escaping Handler = { _ in }) { | |||
| public init(_ input: Node, bufferSize: UInt32 = 1_024, callbackQueue: DispatchQueue, handler: @escaping Handler = { _ in }) { | |||
There was a problem hiding this comment.
Line Length Violation: Line should be 120 characters or less: currently 129 characters (line_length)
|
Why don’t we call all the tap callbacks on the main queue? |
|
Hey @wtholliday, I've added a comment on the issue, but copying it here too: I think we should try to avoid dispatching on the main queue from the framework. In case of e.g. If framework does things on the main queue, you have no choice as a consumer. If it doesn’t, and you need it, it is easy to switch to main queue at a call-site. But, putting that aside, I don’t think this solves it either. You might be doing operations on the tap (stop, start) from another queue (as we do). |
Fixes #2814, but it feels clumsy as we have two syncronisation mechanisms - locks and queue.
We should probably rewrite a tap to work on one dispatch queue and remove all the locks.