is JSONSerialization.jsonObject(with: inputStream) reliable? sometimes it works fine (e.g. with small objects) and sometimes it blocks forever (easier to get the block with big objects). yet sometimes it works ok even with big objects. tried to call it on a different queue - didn't help.

hello, how do i create a virtual microphone on macOS that can be selected as a default input device in System Settings or in apps like FaceTime / QuickTime Player / Skype, etc? is Audio HAL plugin the way to go? i've seen this macOS 10.15 note: "Legacy Core Audio HAL audio hardware plug-ins are no longer supported. Use Audio Server plug-ins for audio drivers." though i am not sure if that's applicable, as i can think of these interpretations: 1 "Legacy Core Audio HAL audio hardware plug-ins are no longer supported (but you can still use non-legacy ones.) 2 "Legacy Core Audio HAL audio hardware plug-ins are no longer supported." (but you can still use non-hardware ones".) 3 "Legacy Core Audio HAL audio hardware plug-ins are no longer supported". (if you used that functionality to implement audio hardware drivers then your you can use Audio Server plug-ins instead, otherwise you are screwed.) The "Audio Server plugin" documentation is minimalistic: https://developer.apple.com/library/archive/qa/qa1811/_index.html which leads to a 2013 sample code: https://developer.apple.com/library/archive/samplecode/AudioDriverExamples/Introduction/Intro.html and contains a "nullAudio" plugin and a kernel extension backed plugin - neither of those i wasn't able to resurrect (i'm on macOS Catalina now). any hints?

hello, i know i could be overly paranoid at times.. but is this the case that i need to protect my global memory location (that i read from / write to) with read/write memory barriers even if i'm only accessing that location from a single serial DispatchQueue? considering the fact that GCD can pick a different thread to run operations on that queue, and a further fact that different threads can run on different cores and thus have different L1/L2 caches, so that the barrier unprotected write to a location in one code invocation (that runs on my serial queue, that happens to be bound to thread1/core1 at the time) might not yet be visible to a different invocation of my code that runs a bit later on the same serial GCD queue but it so happens that now it runs on thread2/core2, so that the barrier unprotected read from that global memory location returns some stale data? is the answer any different if we consider a serial (maxConcurrentCount=1) OperationQueue instead of a serial dispatch queue? finally, is the answer any different if we consider a single NSThread / pthread instead of a serial dispatch queue? can a single thread be bound to different cores during its lifetime? (e.g. work on one core, then sleep, then awake on a different core). thank you.

hello, i don't think it is provided by the system already so i'd like to implement a smart version of DispatchQueue.async function - the one that will not reschedule the block if i am already on the queue in question and call the block directly instead in this case.  extension DispatchQueue { func asyncSmart(execute: @escaping () -> Void) { if DispatchQueue.current === self { // ????? execute() } else { async(execute: execute) } } } the immediate problem is that there is no way to get the current queue (in order to compare it with the queue parameter and do the logic branch). anyone've been through it and solved this puzzle?