Thanks @DTS Engineer . So, for NWConnection (UDP/TCP), when the app goes into the suspended state, it would potentially be defuncted, and upon resumption the stateUpdateHandler would deliver a .failed state. In contrast, for an NWListener (UDP/TCP) that is not registered with Bonjour, it might simply stop listening and become stale, and the application would not receive any notification in this case. Since it can stop listening in this scenario, the recommendation is to proactively close the listener before the app becomes eligible for suspension. Is this a fair understanding? Additionally, does the same semantic apply to the dispatch queue? For example, let's say I have created a serial dispatch queue (which in turn targets a global queue). When my application goes into the suspended state, can the dispatch queue also be defuncted? If yes, is there any notification mechanism that lets the application know that the dispatch queue has been defuncted?

Thanks @DTS Engineer . I understand now that the Network Framework/System ensures that all pending I/Os associated with an NWConnection have their associated completion handlers invoked, even if the application has released its strong references to the NWConnection (after calling cancel(), which will eventually cause the pending I/Os to be cancelled) and the DispatchQueue. So the flow looks like: The application performs an asynchronous I/O which have a completion handler/callback associated with it. The I/O remains pending in the Network framework / underlying I/O machinery. The application calls cancel() on the NWConnection and then releases its own strong references to both the NWConnection and the DispatchQueue. The pending I/O eventually reaches completion or cancellation. The Network framework then schedules the associated completion handler to execute on the connection's queue. Once there is no further work requiring the queue, the Network framework/System can release its internal references/resources associated with the NWConnection and the DispatchQueue, allowing the connection to be fully torn down and the queue to be deallocated when there are no remaining references. Is the above understanding correct?

Thanks @DTS Engineer . I understand that NWConnection needs to invoke all completion handlers for the pending I/O operations associated with it. Just to confirm my understanding of the completion-handler case: Suppose an NWConnection has some outstanding I/O operations with completion handlers registered. If the application calls cancel() and then releases its strong references to both the NWConnection and the DispatchQueue passed to connection.start(queue:). Since those completion handlers must execute on the connection's queue, does this mean that Network framework internally keeps the necessary connection/queue resources alive after the application releases its references, until all outstanding completion handlers have been invoked and have returned? In other words, is it correct to think of the lifecycle as: The application calls connection.cancel(). The application releases its references to the NWConnection and the DispatchQueue. Network framework retains the necessary internal state and the queue because outstanding completion handlers still need to be delivered. The pending completion handlers are invoked on the connection's queue. Once all completion handlers have returned, Network framework can release its internal references to the queue and complete the connection's teardown. Or, alternatively, is the application expected to track all pending I/O operations and retain the DispatchQueue reference until all completion handlers have been delivered? If so, would releasing the queue reference before all completions are delivered cause any issue, or would it simply be retained internally by Network framework? I want to confirm whether the application needs to explicitly manage this lifetime, or whether Network framework manages the queue's lifetime internally until all outstanding completion handlers have completed.

Hi @DTS Engineer, I have one doubt here related to the lifecycle aspect of the Dispatch Queue associated with a NWConnection instance. Let's assume I have a NWConnection instance, I associate it with a dispatch queue using start(queue:) API such that the network os events for the NWConnection instance can be delivered to this queue by the OS. My understanding is that the association would have result in NWConnection holding a strong reference towards the 'Dispatch Queue' object. Now, I perform some I/O (send/receive) on the NWConnection instance and immediately perform the below mention steps. Also assume that the completion closures for those I/O operations do not capture or otherwise retain the NWConnection. Call connection.cancel() and then release my last strong reference to the NWConnection. Without waiting for the connection to transition to the .cancelled state, I also release my last strong reference to the associated DispatchQueue. My question here is: Does NWConnection, during its teardown, retain the DispatchQueue until the cancellation completions for all pending I/O operations associated with the connection have been delivered/executed, given that the application no longer holds any strong references to either the NWConnection or the DispatchQueue? Or, once cancel() is called, does NWConnection immediately release its reference to the dispatch queue, now whether the pending callbacks are ultimately executed depends on whether the application has kept the queue alive?

Thanks @DTS Engineer . I now understand that the dispatch queue holds a strong reference to the closures, and those closures are only released once they run. If the queue is suspended and the closures never execute, those references are never released and the memory remains retained indefinitely. In my case, I suspended the dispatch queue only to simulate certain scenarios - I don’t intend to suspend the queue. My main question was whether, after calling .cancel() on an NWConnection, I need to wait for confirmation from the OS that the pending I/O has actually been cancelled. Based on our discussion on the thread, my understanding is that I do not need to wait. Is that correct? To restate the scenario: If I call .cancel() on the NWConnection and then release my own reference to the dispatch queue (e.g., set it to nil), the NWConnection still holds a strong reference to that queue. So the queue won’t be released until the NWConnection itself completes its teardown. My understanding is that .cancel() begins tearing down the NWConnection, and even if cancellation of the pending I/O is delayed, the NWConnection will eventually drop its reference to the queue as part of its cleanup, without waiting for any pending send/receive closures to execute. Since the closures themselves do not hold a strong reference back to the NWConnection, the teardown does not wait for those closures to run before releasing its reference to the queue. Right?

Thanks @DTS Engineer, However, that’s not a problem because, in general, you shouldn’t rely on releasing the last reference to cancel the connection. Rather, you should call cancel() on it. That’s guaranteed to complete all the outstanding receives which breaks any retain loops they might’ve formed. Some Questions: When we call .cancel, the teardown begins and all pending receives are supposed to be cancelled. If I suspend the dispatch queue on which async events for the NWConnection are delivered, the cancellation callbacks will not be invoked. In that case, will the reference held by the receive closure remain unreleased, potentially causing a memory leak if the receive closure holds a strong reference to another object? 2 And if the receive closure does not hold a strong reference, then even if the callback is not invoked, it should not be a problem, right?

Thanks @DTS Engineer , No. From the perspective of Network framework, the cancellation will proceed asynchronously and that’s just fine. However, it’s easy to think of cases where you might need to do that due to considerations in your code. Imagine, for example, that you have a listener controlled by a Start / Stop button. If the user clicks Stop and then immediately clicks Start, bad things might happen if the cancellation is still in progress. In that case, you’d want to show a status of stopping and not enable the Start button until the cancellation is complete. I understand that the application does not need to wait for OS confirmation, and it can simply exit and that this is safe to do. However, in the case where I am restarting my application, it seems possible that if I restart without waiting for the listener’s cancellation confirmation, I might not be able to open the listener on the same port because it is still busy, resulting in a 'port/address in use' error. Is this understanding correct, and are there any implications other than this?

Thanks, @DTS Engineer (Kevin). I think there's been a misunderstanding regarding my doubt about the OperationQueue concurrency limit. Since I’m using an OperationQueue with a defined concurrency limit, the number of tasks executing concurrently depends on this limit. As I am the one scheduling tasks through the OperationQueue, the concurrency level will be controlled by the set limit. Now, in the case of Apple's Network Framework, we need to provide a dispatch queue (The queue on which listener events are delivered). If I pass the same dispatch queue that the OperationQueue uses internally, will this affect the number of callbacks executed concurrently? Or does the OperationQueue concurrency limit have no impact on callback execution?

Hi @DTS Engineer (Kevin), Concurrent queues are a relatively late addition to the API and, IMHO, are something that you should actively avoid, as they create exactly the same issues as the global concurrent queues.The ONE exception to that is cases where you're specifically trying to create a limited amount of parallel activity with a specific component ("up to 4 jobs at once"). IF that's the case, then the correct solution would be to use NSOperationQueue to set the width. As a side note here, NSOperationQueue is actually the API I would recommend over dispatch for case where you want something that works like GCD. It's built as a wrapper around dispatch, however, it also provides things like a common work object base class, cancellation, progress, etc. It also exports the underlying GCD queue, so you can also use it with any API that requires a GCD queue. As per your suggestion i tried using OperationQueue, which provide[s] us the capability of controlling the number of Concurrent Task[s] by specifying the maxConcurrentTask[s] property of the Operation Queue. To test this, I created an OperationQueue with QOS set to default and concurrent attributes to allow multiple tasks to run in parallel. I then set maxConcurrentOperationCount = 2 and passed the queue to the .start call of NWListener. Next, I sent 10 concurrent connections from another machine to observe whether only 2 connections would be processed at a time. However, despite setting maxConcurrentOperationCount, all 10 connections were handled simultaneously. It appears that the underlying dispatch queue is bypassing the concurrency limit. import Network import Foundation var operation_queue = OperationQueue () operation_queue.underlyingQueue = DispatchQueue (label: "test_operation_queue", qos: .default, attributes: .concurrent) operation_queue.maxConcurrentOperationCount = 2 do { var params = NWParameters(tls: NWProtocolTLS.Options (), tcp: NWProtocolTCP.Options()) let listener = try NWListener(using: params, on: 52000) // Use a specific port listener.stateUpdateHandler = { state in switch state { case .setup: print("Setup state") case .waiting(let error): print("Waiting state with error: \(error)") case .ready: print("Server is ready on port \(listener.port ?? 0)") case .failed(let error): print("Failed state with error: \(error)") case .cancelled: print("Cancelled state") @unknown default: print("Unknown state") } } listener.newConnectionHandler = {connection in print ("Connection Received and processing Started") } listener.start(queue: operation_queue.underlyingQueue!) } catch { print("Failed to create listener: \(error)") } Am I missing something here?

@DTS Engineer I know this that swift::Bool is compatible with c++ bool. What I wanted to ask is that in the documentation it is mentioned that Swift exposes UnsafeMutablePointer to C++ (link). Quote Pointer types, like OpaquePointer, UnsafePointer, UnsafeMutablePointer, UnsafeRawPointer and UnsafeMutableRawPointer UnQuote I directly want to use them in c++ as swift::UnsafeMutablePointer. If it's not true what documentation mean, then what is the manifestation for exposing these UnsafeMutablePointer?

@DTS Engineer I got your point and i was able to use the pointer in that way. public func ReturnInteger() -> UnsafeMutablePointer<Int32> { withUnsafeMutablePointer(to: &value) {pointer in return pointer } } void CppClass::GetIntegerPointer() noexcept { int32_t * x = (int32_t *)Interop::ReturnInteger(); // The above way works but when i am trying to directly use // swift::UnsafeMutablePointer<int32_t> x = (int32_t *) Interop::ReturnInteger (); // it gives build error that UnsafeMutablePointer not found . } But in the documentation it's mentioned that it is exposed to C++. Quote Pointer types, like OpaquePointer, UnsafePointer, UnsafeMutablePointer, UnsafeRawPointer and UnsafeMutableRawPointer UnQuote Can you Explain what does this mean?

@Claude31 I can't use class type as this Data instance is provided to me by the OS whenever my Completion is been called w.r.t Receive. Now I want to use this data instance in C++. For which basically I create a wrapper class over this and pass it as Opaque to C++. Code Snippet class DataHolder { init () {} public var data_wrapper : Data? } func ReceiveHandler (_ pContent : Data? ) -> UnsafeMutablePointer { // pContent is only valid inside scope of this function . // Create a instance of wrapper class var x = DataHolder.init () // Copy being created here. x.data_wrapper = pContent return Unmanaged.passRetained (x).toOpaque () } Problem is copy creation each time which i want to prevent.

@DTS Engineer Thanks I got the clarity regarding the ARC. I have a usecase where I get a Data Object in the CallBack I Register during the receive call. I want to pass the same Data Object to C++ without creating a Copy and ensuring that it remains valid until i am done with my operations in C++. Is there a way for that?

Hi @DTS Engineer, withUnsafeBytes is Deprecated with data Now, is there any other alternative way to do this. Also just wanted to confirm that within the closure the Pointer to the bytes will always remain valid and it's ARC will not be decremented any how?

Yes It's related to Active Directory. Here I am not referring to the FQDN of the interfaces through which we are connected to Internet. Just like hostname which helps us to identify a machine in a network. We can use network-name (local domain name) which is assigned to a machine and doesn't depend on the interfaces, which can be used as an alternative of an IP-address. Fully Qualified Domain Name which i means is hostname + network name (local domain name) which can be used to communicate with a machine.